GetWindowsDirectory retrieves wrong directory under Terminal Servi

[Darren Fitzgibbon]

We have an application written in C# and compiled about 2 years ago with
Visual Studio 2005. This application is supports one of our legacy VB6
applications and needs to read the legacy application's INI file from the
Windows directory. Under a normal standalone install this is usually the
C\Windows folder, however under Terminal Services/Citrix the INI file is
mapped to a Windows folder within their profile. The C# application uses
GetPrivateProfileString and GetWindowsDirectory from the kernel32 library, in
the original build this worked, but we have had cause to recompile the
application without any changes to the INI file support classes, since
recompliing the application only picks up the system's Windows folder not the
user profile Windows folder.

In side by side tests on the same terminal services machine, the original
build still behaves correctly, the legacy VB6 app behaves correctly, and new
builds of the C# app fails to get the folder from the user profile. I have
rebuilt the C# app with both VS2005 and VS2008 with the same results.

Does anyone know why the old application works but the same code now fails.

Regards Darren

 

[Ciaran O''Donnell]

I would suggest it has something to do with either one of the changes you
made which you dont think affected this, or potentially the way it has been
installed into Citrix. Its almost impossible to tell without a copy of the
source or assemblies to compare them. Check out the two versions in
Reflector, or better yet, use reflector and the dissassemler adding to
generate projects from the old and new version of the app, then use a good
compare tool like beyond compare to compare them, That should show the
differences, then work through those to find the issue.

HTH

 

[Darren Fitzgibbon]

Thanks but I have already rolled back my changes in SourceSafe to the point
of the last build, and it still doesn't work. I have also created a test
project which only contains a simple Windows form with a couple of text boxes
and a button and pasted in the original code to import the api functions,
this also fails.
We use the same api in VB6, I created a simple VB6 DLL and referenced it
from my C# test app and also a VB6 test app. From C# it fails, from VB6 it
works. This points me to the fact that the context that the C# app is built
with is changing the APIs behaviour.

 

[Ciaran O''Donnell]

Ok, I think your new compiled C# app has the Terminal Services aware flag
turned on in the header. I guess this is a change made by framework SP1 or
something.
Try running this in the visual studio command prompt

link.exe /EDIT /TSAWARE:NO yourexe.exe

Let us know how it goes.

 

[Darren Fitzgibbon]

Thanks that works a treat, although I am puzzled as to how you arived at the
solution, I can't find any documentation relating to running the linker in
edit mode.

I did however found an entry on the Visual Studio feedback blog/forum with a
response from a MS employee, who basically said 'Yes we did change the linker
setting to TSAWARE = true, but there is no way of changing the default.',
helpful I think not.

Any how using the command line provided, I have constructed a batch file
which sets the environment to match that of the VS Cmd Prompt then calls the
linker to flip the TSAWARE flag back to false. I have placed this file in a
solution folder and call it from the Post Build event of the EXE that I need
to be in Legacy (Non-TSAWARE) mode.

The batch file (tsaware.bat) contains the following two lines

call "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
link.exe /EDIT /TSAWARE:NO "%1"


and the Post Build Event contains

$(SolutionDir)tsaware.bat "$(TargetDir)$(TargetFileName)"


This way every time the EXE is built its placed in Legacy mode.