System.Environment.GetFolderPath bug?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

schneider - 08 Sep 2008 23:59 GMT

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

Reply to this Message

schneider - 09 Sep 2008 00:03 GMT

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

>I seem to get different values for the below code depending on how this is
>called....
[quoted text clipped - 18 lines]
> Thanks,
> Schneider

Reply to this Message

Jeff Gaines - 09 Sep 2008 02:58 GMT

On 09/09/2008 in message <eM$n7bgEJHA.1268@TK2MSFTNGP05.phx.gbl> schneider
wrote:

>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?

Signature

Jeff Gaines Damerham Hampshire UK
This is as bad as it can get, but don't bet on it

Reply to this Message

schneider - 09 Sep 2008 04:04 GMT

My app can run as both; targets any CPU.

> On 09/09/2008 in message <eM$n7bgEJHA.1268@TK2MSFTNGP05.phx.gbl> schneider
> wrote:
[quoted text clipped - 4 lines]
>
> VS is a 32 bit app and your app is 64 bit?

Reply to this Message

Jeff Gaines - 09 Sep 2008 07:36 GMT

On 09/09/2008 in message <ecuZhiiEJHA.4336@TK2MSFTNGP05.phx.gbl> schneider
wrote:

>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?

Signature

Jeff Gaines Damerham Hampshire UK
If it's not broken, mess around with it until it is

Reply to this Message

Hongye Sun [MSFT] - 09 Sep 2008 11:08 GMT

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 (hongyes@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:
msdnmg@microsoft.com.

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

Reply to this Message

schneider - 10 Sep 2008 22:27 GMT

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

Thanks,

Schneider

> Hello Schneider,
>
[quoted text clipped - 63 lines]
> This posting is provided "AS IS" with no warranties, and confers no
> rights.

Reply to this Message

Hongye Sun - 12 Sep 2008 04:11 GMT

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 (hongyes@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:
msdnmg@microsoft.com.

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

Reply to this Message

schneider - 12 Sep 2008 05:42 GMT

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

> Hi Schneider,
>
[quoted text clipped - 43 lines]
> This posting is provided "AS IS" with no warranties, and confers no
> rights.

Reply to this Message

Hongye Sun [MSFT] - 12 Sep 2008 09:09 GMT

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 (hongyes@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:
msdnmg@microsoft.com.

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

> Thanks for the code,
>
[quoted text clipped - 55 lines]
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.

Reply to this Message

System.Environment.GetFolderPath bug?

Free Magazines