Page 1 of 2

.NET Problems on Server 2003

Posted: Wed Aug 22, 2007 11:43 am
by Craig Daniel
We're still evaluating IA7 before buying, but I've hit a serious snag which honestly could be a deal-breaker. I really need the scripting and upgrade flexibility I have in IA and in the future, web media will probably be useful as well. So I really want this work.

When installing our product on Windows Server 2003 R2, Register Assembly just does not work. Calling regasm to do the equivalent also does not work. These work fine on Vista (tested), and presumably on XP in Win 2K (have not tested these yet). The correct version of .NET (2.0) is installed. I have posted this same problem in the tech support forum and there are no answers forthcoming. Others appear to have this same (or similar) problem.

If it truely does not work, is there a work-around? Does it work and I'm just doing something wrong?

What version of MSI Installer needs to be present on the target machine? Could this be part of my problem?

Posted: Wed Aug 22, 2007 7:49 pm
by CandiceJones
Did you try running regasm on the command line, to see what happens?

.NET Problems on Server 2003

Posted: Thu Aug 23, 2007 12:21 pm
by Craig Daniel
Sorry, I forgot to mention that. Yes, running regasm from a command prompt works just fine.

Posted: Thu Aug 23, 2007 12:56 pm
by CandiceJones
Then running it from InstallAware should work! At least using the Run Program or Run Program As command :)

Register Assembly problems on Server 2003

Posted: Wed Oct 03, 2007 12:27 pm
by Craig Daniel
Some additional experiments: Moved the register assembly part to the end of the script to make sure all other setup had been done before registering the assemblies. No help.

Tried pausing (via message box) right before the register asssembly part. Went to a dos box and was able to call regasm successfully. Let the script continue and its call to regasm fails with return code -1. Use of the Register Assembly command also does not work and does not produce any error information.

I also noticed that the registering part of the script goes by awfully quickly considering it takes 1 or 2 seconds for a single call to regasm, and I have several calls in there. I suspect that regasm is, in fact, not even running. Anyone know what -1 means as a return code from Run Program when calling regasm? Is that coming for regasm, or from the installer script engine?

Also tried putting in a call to Notepad.exe (something I can see whether its running) and task manager confirms that notepad is running as the administrator user (the user I'm logged in as). So it seems there should not be any permissions problems.

Any ideas? Anyone?

Posted: Wed Oct 03, 2007 3:21 pm
by CandiceJones
If you are getting -1, that means you're not specifying a valid path to regasm.exe in the Run Program command.

Did you try pressing F1 while the Run Program dialog box is showing? The meaning of the -1 return code is already explained there.

For your convenience, -1 means "program to run not found".

Server 2003 R2 problem solved!! Possible bug in IA.

Posted: Wed Oct 03, 2007 4:57 pm
by Craig Daniel
Thanks Candice. Your last post got me looking in the right direction. I found the problem and it's strange.

According to your documentation, a -1 return from Run Program simply means it couldn't run the program for whatever reason. In this case it WAS a bad path to regasm.

Here's the strange part. What I was passing to Run Program was exactly this: "$WINDIR$\\Microsoft.NET\\Framework\\v2.0.50727\\regasm" which works fine on my other test machines. I stuck in a message box and displayed the value of $WINDIR$ and here's what it has in it: "C:\\Documents and Settings\\Administrator\\WINDOWS\\". That is NOT the Windows directory. The variable WINDIR was loaded using "Get Folder Location System->Windows Directory toward the beginning of the script where the wizard originally put it.

I solved this by using $WINSYSDIR$\\..\\Microsoft.NET\\Framework ... etc.

Also, it appears to be the case that whatever IA does when I use the Register Assembly command is also affected by the wrong value of WINDIR because it doesn't work either.

This smells like a bug in IA (or Windows) to me.

Posted: Thu Oct 04, 2007 12:53 am
by CandiceJones
If WINDIR is reported wrong, then it means that the computer where it's wrong has its registry corrupted, where the Windows APIs related to folder paths obtain this information from.

This explains why it worked on some machines and not on others.

Posted: Thu Nov 08, 2007 9:30 am
by DavidCassere
I just happened to drift across this issue when looking for something else and it explain why we have been having programs trying to run software from the .net directory.

The "c:\\documents....." directory returned is the override directory for a specific user, this allows individual logins to have different .DLLs etc.

I have changed our script over and hopefully this will fix the problem. It seems as if $WINDIR$ will not always return what you expect.

Posted: Tue Jan 15, 2008 10:18 am
by DiVan

Code: Select all

Get Common Folder Location System->Windows Directory into WINDIR
 
MessageBox: IA, windowsDirectory:$NEWLINE$$NEWLINE$$WINDIR$


on XP result is C:\\WINDOWS
on 2003 : C:\\Documents and Settings\\someuser\\WINDOWS

I need this to call aspnet_regiis.exe to set my v-folder to .net 2.0.
Currently, I pass "native" %windir% to the command line, and it works fine (%windir% results in "C:\\WINDOWS").

Another issue with 2003 server, as mentioned above. IA won't reset IIS to use .net 2.0. (After configured to do so in "Create Virtual Folder" dialog of course). And it works just fine with XP.

I think those are related issues. (someone have to call aspnet_regiis... :))

Posted: Tue Jan 15, 2008 1:16 pm
by CandiceJones
This code returns:

Code: Select all

Get Common Folder Location System->Windows Directory into WINDIRALL
Get Folder Location System->Windows Directory into WINDIRME
MessageBox: WINDIR, All: $WINDIRALL$$NEWLINE$Me: $WINDIRME$

---------------------------
WINDIR
---------------------------
All: C:\\WINDOWS
Me: C:\\WINDOWS
---------------------------
OK
---------------------------


On 32 and 64 bit Server 2003.

The API InstallAware internally uses to obtain this information is GetWindowsDirectory. You should contact Microsoft and determine why the API is returning an invalid result on your system. This API malfunction would certainly cause other problems on your system.

Re: .NET Problems on Server 2003

Posted: Fri Sep 06, 2013 2:16 am
by NormanDerrick
If anyone is still looking into this, the problem still exists with IA 15 and Windows 2008 R2 servers. The problem with the $WINDIR$ pointing to the user's local windows folder is on target as discussed in the original thread by Craig Daniel in 2007. The difference now vs. the 2007 thread is that Craig was using Run Program script statements to invoke RegAsm where he needed to get the correct folder location of the RegAsm.exe whereas I am using the script commands for Register Assembly and Generate Native Images so I have no control over how the IA engine decides where to look for those EXE files.

I have a client where the use of the scripting statements for "Register Assembly" and "Generate Native Images" failed because the .Net utilities were not found in the folder that the IA engine retrieved while executing those script commands. Note that I am not using Run Program in my script so I have no option to use "Get Common Folder" to influence where the "Register Assembly" script command looks for RegAsm, etc

My solution was to copy the RegAsm.exe and nGen.exe along with their .config files into the logged in users roaming Windows folder path C:\Users\admin\windows\Microsoft.Net\Framework\V40.30319. I believe that if roaming is not turned on, then the GetWindowsDirectory() API call would have returned the expected location of C:\Windows

Since this is a very subtle issue, is there anyway that InstallAware can be changed to use the equivalent of "Get Common Folder" fr the script statements like Register Assembly and Generate Native Images?

Thanks,
NormD

Re: .NET Problems on Server 2003

Posted: Tue Sep 10, 2013 5:04 am
by FrancescoT
Dear NormD,

honestly, I suspect that very probably your problem is caused by something else.

By the way, what happens if you try to run regasm from the command line using the same user account?
Could you please post a very minimal sample that replicates your issue?

Regards

Re: .NET Problems on Server 2003

Posted: Tue Sep 10, 2013 9:21 am
by NormanDerrick
Hi Francesco,

In order to run it from the command line I have to explicitely include the path to the folder that contains the file RegAsm.exe and since the command line "knows" where the file is, it runs OK.

I will attempts to costruct a small sample but I will need to get my client to agree to allow me to test it on their server as the problem does not occur on my development/test server - but I do not use raoming profiles.

Thanks.
Norm

Re: .NET Problems on Server 2003

Posted: Tue Sep 10, 2013 11:23 am
by FrancescoT
Dear Norm,

By the way, I suggest you also to have a look at the following link ... maybe it could help you;
http://technet.microsoft.com/en-us/library/cc736881(v=ws.10).aspx

Regards