none
Environment variable encoding suddenly changes when running tests or build events

    Pertanyaan

  • I have a class

        public class Class1
        {
            public string GetUserProfile()
            {
                return Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
            }
        }

    and a test

            public void GetUserProfileTest()
            {
                Class1 target = new Class1();
                string expected = @"C:\Users\Søren\AppData\Roaming";
                string actual;
                actual = target.GetUserProfile();
                Assert.AreEqual(expectedactual);
            }

    During the beginning of a coding session, this test will pass, but often it so happens that after a while the test will start to fail, because the method starts returning

    "C:\Users\S›ren\AppData\Roaming"

    A post-build event will also start echoing %USERPROFILE% as "C:\Users\S›ren", but a console project in the same solution will still write "C:\Users\Søren"

    If I restart Visual Studio everything returns to normal

    I haven't been able to pin-point a specific action that could trigger this change, so I am basically asking, if anyone has come across this behavior and knows the cause and how to fix it.

    I'm on a Danish Win7x64, and in the C:\Users folder there is a C:\Users\S›ren folder with a few AppData entries


    • Diedit oleh s_w_jensen 29 Desember 2011 19:53
    • Dipindahkan oleh lucy-liu 30 Desember 2011 7:12 it is a unit testing issue (From:Visual Studio Editor)
    29 Desember 2011 19:47

Semua Balasan

  • Hi s_w_jensen,

    This issue is about the Unit Testing, in order to offer you a better support, I will move it from the “Visual Studio Editor” forum to “Visual Studio Unit Testing”.

    Thank you for your understanding!

     

    Best regards,

    Lucy


    Lucy Liu [MSFT]
    MSDN Community Support | Feedback to us
    30 Desember 2011 7:10
  • Hi s_w_jensen,

     

    Thank you for posting in the MSDN forum.

     

    A post-build event will also start echoing %USERPROFILE% as "C:\Users\S›ren", but a console project in the same solution will still write "C:\Users\Søren"

     

    If you create a simple console project with the codes like these “Console.WriteLine (@"C:\Users\S›ren");” Whether the output is ”C:\Users\S›ren” or "C:\Users\Søren" ?

     

    I create a simple App with our Computer (Win7x64 English version). I get the result like the following screen shot. So we can make sure that my VS (English version) can distinguish the specific symbol. If your result is not the same, you should check your VS language version.

     

    In addition, I suspect that whether the unit test doesn’t support the specific symbol, so I create a simple unit test for “getString1 ()” method, but it (“›”) can be check.

     

     

    Based on your description, you are using the Danish Win7x64. So my suggestion is that you can create the same app with VS (English version) to check it, so we could make sure that whether it is related to the VS language version. If no help, you can try to run it with another PC, this PC would better install the Win7x64 English version. Check that whether it is related to the system.

    Best Regards,

     


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    02 Januari 2012 6:27
    Moderator
  • Hi Jack and luci-liu

    Thank you for your answers.

    It is not a question of wheather the test enging of Visual Studio does support the Danish letter "ø" or not. As I stated above everything works fine in the beginning of a coding session, and the test does in fact return "C:\Users\Søren\AppData\Roaming" as it is supposed to. My problem is that the behavior changes over time - after a while, the same call will all of a sudden start to return "C:\Users\S›ren\AppData\Roaming" for no apparent reason.

    I'm not sure if it is actually a test-related isssue, since a post-build event will start behaving the same way.

    Regards

    Søren

    (edit: I'm using the English version of VS2010)
    02 Januari 2012 11:08
  • Hi s_w_jensen,

     

    Glad to receive your reply.

     

    If you create a simple console App with the code:

     

    Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData));

     

    Or           

     

    Console.WriteLine(@"C:\Users\Søren");

     

    What is the result? Whether it is “C:\Users\ Søren \AppData\Roaming” or “C:\Users\Søren”?

     

     

    The test does in fact return "C:\Users\Søren\AppData\Roaming" as it is supposed to.

     

    As my understanding, it is not related to unit tests.

     

    I did some research, it may be related the language pack.

     

    1.       You could check that whether the “Current system locale” is changed after the test is failed. Start->Control Panel->Region and Language->Administrative->Change system locale…

    2.       I create the same test as yours, I can run it normally. Of course, my PC user name is “Jack”. So the output is “C:\Users\Jack\AppData\Roaming”. So if possible, I think you can change the Administrator or user name “Søren” to another one which doesn’t have the specific Danish letters like "ø", so it will save your time to do your next action.J

     

    Have a nice day,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    03 Januari 2012 5:07
    Moderator
  • Hi s_w_jensen,

     

    I am writing to check the status of the issue on your side.

    What about this problem now?

    Would you mind letting us know the result of the suggestion?

     

    Best Regards,

     


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    06 Januari 2012 4:28
    Moderator
  • Hi Jack

    Sorry for the delay.

    As I stated in the original post a console app in the same solution will continue to write out C:\Users\Søren, also when the test and the post-build starts to write C:\Users\S›ren.

    The Current System Locale doesn't change.

    It is not really an option to change my user name - I can't control the names of other developers or end users.

    Best regards.

    09 Januari 2012 4:29
  • Hi s_w_jensen,

     

    Can you share the whole error message when the test is failed? Can you give us a screen shot about the failed unit test?

     

    As you said, if we use “string expected = @"C:\Users\ S›ren\AppData\Roaming";”, run the test, whether the unit test is failed? If it is failed, please sharing the error message.

     

    Best Regards,

     


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us
    09 Januari 2012 5:01
    Moderator

  • Hi Jack

     

    Here is a screen shot. When I took the screen shot the test would fail when I chose 'run', but still pass, when I chose 'debug'.

     

    Best regards

     

     

    09 Januari 2012 5:29
  • Hi,

    Very interesting question.

    1. Run your VS as the Administrator, run this test again.

    2. As Jack's reply, using "string expected = @"C:\Users\ S›ren\AppData\Roaming", is it failed?

    09 Januari 2012 5:40
  • Hi s_w_jensen,

     

    Glad to receive your reply. It seems that the Actual value changed.

     

    As my last reply “if we use “string expected = @"C:\Users\ S›ren\AppData\Roaming";”, run the test, whether the unit test is failed? If it is failed, please sharing the error message.”

     

    Open the folder “C:\Users”, whether it has the user “S›ren”? Run your VS as the Administrator to check it whether it is related to the Administrator permission.

     

    In addition, I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Thanks


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    10 Januari 2012 6:37
    Moderator
  • As mentioned ealier the error only occurs after working in Visual Studio for some time

    When I start out

                 string expected = @"C:\Users\Søren\AppData\Roaming";

    will pass, and

                string expected = @"C:\Users\S›ren\AppData\Roaming";

    will fail like this:

    Failed GetUserProfileTest TestProject1 Assert.AreEqual failed. Expected:<C:\Users\S›ren\AppData\Roaming>. Actual:<C:\Users\Søren\AppData\Roaming>.  

     

    After a while the error starts occuring and

    string expected = @"C:\Users\Søren\AppData\Roaming";

    will fail as documented in the screen shot

     

    When I restart Visual Studio the behavior reverts to normal - for a while

     

    If I start Visual Studio with administrative privileges what should I be looking for?

     

    If the file system the folder C:\Users\S›ren do exsist, and there are a few subfolders in the AppData folder,
    from Google, Microsoft and HP among others, but this is not the actual Profile folder, of course.

    10 Januari 2012 12:24
  • When I am testing VSTO-solutions and the error happens, Word will throw up a dialog, causing all tests to fail.

    It says that the autocorrect file cannot be saved, suggesting that it could be due to write protection or insufficient user rights. The file is found in "C:\Users\Søren\AppData\Roaming\Microsoft\Office", so the error is probably caused by Word trying to access "C:\Users\S›ren" instead.


    Edit:

    When I actually created the folder "C:\Users\S›ren\AppData\Roaming\Microsoft\Office" and copied the autocorrect file, the dialog box did not appear. Instead I got a generic exception, when callling word.Documents.Add():

    Initialization method TestCore.WordControllerTest.MyTestInitialize threw exception. System.Runtime.InteropServices.COMException: System.Runtime.InteropServices.COMException: Der opstod en fejl i Word..

    (An error occured in Word)

    This tells me that Word is in fact getting the wrong path when trying to resolve the UserProfile-path


    (still s_w_jensen speaking - wrong LiveID)
    25 Januari 2012 22:01
  • Dear s_w_jensen,


    Your question falls into the paid support category which requires a more in-depth level of support. Please visit the below link to see the various paid support options that are available to better meet your needs.
    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

    Thanks!


    Sophia Lu [MSFT]
    29 Januari 2012 9:08