System.Environment.GetFolderPath bug?

[schneider]

I seem to get different values for the below code depending on how this is
called....

Dim p As String

p =
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles)


Returns the following in design mode (Win Forms designer):

"C:\Program Files (x86)\Common Files"


Returns the following in runtime mode:

"C:\Program Files (x86)\Common Files"


I'm running on Win XP64 pro.

Can anyone explain this? Seems to be a bug to me?

Thanks,
Schneider

[schneider]

Sorry typo one call returns with the (x86) the other does not see corrected
below:


Dim p As String

p =
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles)



Returns the following in design mode:

"C:\Program Files (x86)\Common Files"



Returns the following in runtime mode:

"C:\Program Files\Common Files"


I'm running on Win XP64 pro.

Can anyone explain this? Seems to be a bug to me?

Thanks,
Schneider

Post by schneider
I seem to get different values for the below code depending on how this is
called....
Dim p As String
p =
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles)
"C:\Program Files (x86)\Common Files"
"C:\Program Files (x86)\Common Files"
I'm running on Win XP64 pro.
Can anyone explain this? Seems to be a bug to me?
Thanks,
Schneider

[Jeff Gaines]

Post by schneider
I'm running on Win XP64 pro.
Can anyone explain this? Seems to be a bug to me?

VS is a 32 bit app and your app is 64 bit?

[schneider]

My app can run as both; targets any CPU.

Post by Jeff Gaines

Post by schneider
I'm running on Win XP64 pro.
Can anyone explain this? Seems to be a bug to me?

VS is a 32 bit app and your app is 64 bit?
--
Jeff Gaines Damerham Hampshire UK
This is as bad as it can get, but don't bet on it

[Jeff Gaines]

Post by schneider
My app can run as both; targets any CPU.

In that case it will default to 64 bit on XP 64. What happens if you
compile it for x86?

[Hongye Sun [MSFT]]

Hello Schneider,

As Jeff said, Visual studio can be run in WOW64, but it is a 32-bit
application.
References:
64-bit and Visual Studio 2005:
http://blogs.msdn.com/deeptanshuv/archive/2006/04/11/573795.aspx
Adam Braden clarification for Visual Studio 2008:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2311722&SiteID=1

I have do a test on my 64bit environment. I compiled the following code
into AnyCPU, x86 and x64.
static void Main(string[] args)
{

Console.WriteLine(System.Environment.GetFolderPath(Environment.SpecialFolder
.CommonProgramFiles));
Console.ReadLine();
}
The outputs are:
AnyCPU:
C:\Program Files\Common Files

x86:
C:\Program Files (x86)\Common Files

x64:
C:\Program Files\Common Files

In 32bit process, it can only load and run 32bit DLL. In 64bit process, it
can only load and run 64bit DLL or EXE.

Now we can explain your symptom:
Because VS.net is a 32bit application, it will be run as 32bit process in
64bit windows. When hosting the designer, it will load and run your program
DLL or EXE. At this time, since your DLL or EXE is compiled for any CPU and
the hosting process is 32bit, it is loaded and run as a 32bit application.
So the output is "C:\Program Files (x86)\Common Files".

Then running the application directly in 64bit windows. It is automatically
run as a 64bit application. At this time, it will output "C:\Program
Files\Common Files".

Now we can conclude that the cause of the issue is that VS.net is a 32bit
application.

Here is a good resource for you to understand programming in 64bit
application: http://msdn.microsoft.com/en-us/library/ms241064.aspx

Please let me know if you still have any question about my reply. I will
try my best to explain it to you. Thanks.

Regards,
Hongye Sun (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

[schneider]

Yes, That what I fugured was happening.
I would consider this a bug. How can I work arround this bug?

Thanks,

Schneider

Post by Hongye Sun [MSFT]
Hello Schneider,
As Jeff said, Visual studio can be run in WOW64, but it is a 32-bit
application.
http://blogs.msdn.com/deeptanshuv/archive/2006/04/11/573795.aspx
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2311722&SiteID=1
I have do a test on my 64bit environment. I compiled the following code
into AnyCPU, x86 and x64.
static void Main(string[] args)
{
Console.WriteLine(System.Environment.GetFolderPath(Environment.SpecialFolder
CommonProgramFiles));
Console.ReadLine();
}
C:\Program Files\Common Files
C:\Program Files (x86)\Common Files
C:\Program Files\Common Files
In 32bit process, it can only load and run 32bit DLL. In 64bit process, it
can only load and run 64bit DLL or EXE.
Because VS.net is a 32bit application, it will be run as 32bit process in
64bit windows. When hosting the designer, it will load and run your program
DLL or EXE. At this time, since your DLL or EXE is compiled for any CPU and
the hosting process is 32bit, it is loaded and run as a 32bit application.
So the output is "C:\Program Files (x86)\Common Files".
Then running the application directly in 64bit windows. It is
automatically
run as a 64bit application. At this time, it will output "C:\Program
Files\Common Files".
Now we can conclude that the cause of the issue is that VS.net is a 32bit
application.
Here is a good resource for you to understand programming in 64bit
application: http://msdn.microsoft.com/en-us/library/ms241064.aspx
Please let me know if you still have any question about my reply. I will
try my best to explain it to you. Thanks.
Regards,
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
This posting is provided "AS IS" with no warranties, and confers no rights.

[Hongye Sun]

Hi Schneider,

I understood this behavior is not expected in some situations. However, we
could not consider it as a bug. That is because WOW64 has design purpose to
change the environment variables in runtime.
As documented at WOW64 Implementation Details
(http://msdn.microsoft.com/en-us/library/aa384274.aspx), it said:
"Environment variables are changed for compatibility when a 32-bit process
is created by a 64-bit process, or when a 64-bit process is created by a
32-bit process. WOW64 changes the following environment variables."

Not only "CommonProgramFiles", environment variable
"PROCESSOR_ARCHITECTURE" and "ProgramFiles" are all changed.

However, we can reference to 64bit "CommonProgramFiles" by
"CommonProgramW6432" in 32bit process. Hopefully, this gives us a chance
to work around your problem. Please use the following method to replace the
original "System.Environment.GetFolderPath" method.
public string GetCommonProgramsFolder()
{
string commonProgramFolder =
System.Environment.GetEnvironmentVariable("CommonProgramW6432");
if (string.IsNullOrEmpty(commonProgramFolder))
{
commonProgramFolder =
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFile
s);
}
return commonProgramFolder;
}

Please try the solution above. I will wait for your reply to see if I can do
any further help. Thanks.

Regards,
Hongye Sun (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

[schneider]

Thanks for the code,

But it's still a bug. http://en.wikipedia.org/wiki/Software_bug
I wonder how many things this is breaking. It's things like this that are
causing problems on the 64bit OS.
How many other places could this be happening?

Thanks,
Eric Schneider

Post by Hongye Sun
Hi Schneider,
I understood this behavior is not expected in some situations. However, we
could not consider it as a bug. That is because WOW64 has design purpose
to change the environment variables in runtime.
As documented at WOW64 Implementation Details
"Environment variables are changed for compatibility when a 32-bit process
is created by a 64-bit process, or when a 64-bit process is created by a
32-bit process. WOW64 changes the following environment variables."
Not only "CommonProgramFiles", environment variable
"PROCESSOR_ARCHITECTURE" and "ProgramFiles" are all changed.
However, we can reference to 64bit "CommonProgramFiles" by
"CommonProgramW6432" in 32bit process. Hopefully, this gives us a chance
to work around your problem. Please use the following method to replace the
original "System.Environment.GetFolderPath" method.
public string GetCommonProgramsFolder()
{
string commonProgramFolder =
System.Environment.GetEnvironmentVariable("CommonProgramW6432");
if (string.IsNullOrEmpty(commonProgramFolder))
{
commonProgramFolder =
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFile
s);
}
return commonProgramFolder;
}
Please try the solution above. I will wait for your reply to see if I can
do any further help. Thanks.
Regards,
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
This posting is provided "AS IS" with no warranties, and confers no rights.

[Hongye Sun [MSFT]]

Hi Schneider,

Thank you for your valuable feedback. I fully understand your concern and
frustration. This behavior makes same code work differently in 32bit and
64bit processes, and that may cause unexpected problems when a developer is
not aware of it. We will report your feedback and questions to the MS
product department, and make sure they fully understand your concern.

In the meanwhile, I will also suggest you to submit the feedback at:
http://connect.microsoft.com/VisualStudio. Your feedback is valuable to MS!

I am very glad that the workaround code works for you. I look forward to
more and more successful cooperation with you in future.

Regards,
Hongye Sun (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

Post by schneider
Thanks for the code,
But it's still a bug. http://en.wikipedia.org/wiki/Software_bug
I wonder how many things this is breaking. It's things like this that are
causing problems on the 64bit OS.
How many other places could this be happening?
Thanks,
Eric Schneider

Post by Hongye Sun
Hi Schneider,
I understood this behavior is not expected in some situations. However,
we could not consider it as a bug. That is because WOW64 has design
purpose to change the environment variables in runtime.
As documented at WOW64 Implementation Details
"Environment variables are changed for compatibility when a 32-bit process
is created by a 64-bit process, or when a 64-bit process is created by a
32-bit process. WOW64 changes the following environment variables."
Not only "CommonProgramFiles", environment variable
"PROCESSOR_ARCHITECTURE" and "ProgramFiles" are all changed.
However, we can reference to 64bit "CommonProgramFiles" by
"CommonProgramW6432" in 32bit process. Hopefully, this gives us a chance
to work around your problem. Please use the following method to replace the
original "System.Environment.GetFolderPath" method.
public string GetCommonProgramsFolder()
{
string commonProgramFolder =
System.Environment.GetEnvironmentVariable("CommonProgramW6432");
if (string.IsNullOrEmpty(commonProgramFolder))
{
commonProgramFolder =
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFile
s);
}
return commonProgramFolder;
}
Please try the solution above. I will wait for your reply to see if I can
do any further help. Thanks.
Regards,
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
This posting is provided "AS IS" with no warranties, and confers no rights.