Tuesday, January 21, 2014

“Microsoft .NET Framework 4 (x86 and x64) and Update for .NET Framework 4 (KB2468871)” ClickOnce Bootstrapper always installs a Japanese Language Pack

Now this is a nasty one I discovered quite recently:

Due to an error in the Microsoft .NET Framework 4 (x86 and x64) and Update for .NET Framework 4 (KB2468871) bootstrapper package, the ClickOnce setup you create in Visual Studio will always install a Japanese Language Pack - provided you selected ANY deployment language in Visual Studio.

This behavior is caused by an incorrect link in the language resource XML file located in your Program Files folder.

For example, if your project’s deployment language is Czech, the XML file is located in:

c:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Packages\DotNetFX40KB2468871\cs\Package.xml

There, under the name DotNetFX40FullLanguagePackBootstrapper, you can find this URL:

http://go.microsoft.com/fwlink/?linkid=164199&clcid=0x411

If you substitute the & for an & and test the link in your browser, you will see that it tries to download a Japanese version of the Language Pack. The correct link for the Czech Language Pack would be ending with clcid=0x405.

This is unfortunately true not only for Czech, but for all the language resource XML files for this bootstrapper, so unless you plan to install a Japanese Language Pack or you don’t need any Language Pack at all, you should probably fix this.

The fix is relatively straightforward, just correct the link in each of the language resource XML files. I hate to do this manually every time so I created a simple installation script that helps me out. Feel free to use it if you like!

Tuesday, November 12, 2013

Async / await for .NET Framework 4 and Stack Trace

If you find yourself wanting to use the async / await language of .NET Framework 4.5 but still need to target Windows XP, what you need is called Microsoft Async Targeting Pack.

The last .NET Framework that is supported on Windows XP is version 4. To allow for the new async / await features in .NET Framework 4, Microsoft came out with an “extension” to the Framework called Microsoft Async Targeting Pack. It is basically a set of DLLs which you can get as a NuGet package.

There are two packages you can choose from. The original one is called Async Targeting Pack for Visual Studio 11, which was later superseded by Async for .NET Framework 4, Silverlight 4 and 5, and Windows Phone 7.5 and 8.

If you go with the new one, as I originally did with my applications, sooner or later you hit one problem. Whenever an exception is thrown in a an async code, you will not get a stack trace information you would expect. Consider the following example:

private async void Button1_Click(object sender, RoutedEventArgs e)
{
try
{
await DoSomethingAsync();
}

catch (Exception ex)
{
Debug.Write(ex.StackTrace);
}
}

public async Task DoSomethingAsync()
{
await TaskEx.Run(() =>
{
throw new ApplicationException("My Application Exception");
});
}

The code is relatively straightforward. You click a button which runs an async method. This method throws an exception in its body. Once the exception propagates back to the click event handler, you catch it and write the stack trace information in the debug output.

If you run the code with Async for .NET Framework 4, Silverlight 4 and 5, and Windows Phone 7.5 and 8, you get the following output:

at Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter.GetResult()
at WpfApplication1.MainWindow.<Button1_Click>d__0.MoveNext() in c:\Data\SkyDrive\Development\Projects\Test\WpfApplication1a\WpfApplication1\MainWindow.xaml.cs:line 34

The only thing you get to know is that the error was caught at line 34. There is no information about the real exception source at line 47. As you can imagine, this can easily make the debugging of your applications a nightmare.

Searching the web, I found some explanations as to why this is happening, what stack trace is and is not supposed to show, etc. I even found a few workarounds (a custom code you need to write in order to get the information you would expect), but that was not a way I wanted to go.

Later I found a much simpler solution. It turns out that if you run the code with the “earlier” or “older” version of the async targeting pack, the Async Targeting Pack for Visual Studio 11, the same code produces much friendlier stack trace:

Server stack trace: 
at WpfApplication1.MainWindow.<DoSomethingAsync>b__3() in c:\Data\SkyDrive\Development\Projects\Test\WpfApplication1a\WpfApplication1\MainWindow.xaml.cs:line 47
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()

Exception rethrown at [0]:
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at WpfApplication1.MainWindow.<DoSomethingAsync>d__5.MoveNext() in c:\Data\SkyDrive\Development\Projects\Test\WpfApplication1a\WpfApplication1\MainWindow.xaml.cs:line 45

Exception rethrown at [1]:
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at WpfApplication1.MainWindow.<Button1_Click>d__0.MoveNext() in c:\Data\SkyDrive\Development\Projects\Test\WpfApplication1a\WpfApplication1\MainWindow.xaml.cs:line 34

Now, that is the way to go!

There is one more gotcha, however. If you’re trying to install the Async Targeting Pack for Visual Studio 11 via Manage NuGet Packages tool in Visual Studio, you will not be able to find the package. This has been done by Microsoft so that people will always install the newer version if the are getting the package for the fist time. The older version of the package however is still available. To get it, you need to use the Package Manager Console and enter the following command:

PM> Install-Package Microsoft.CompilerServices.AsyncTargetingPack -Version 1.0.1

And that should take care of the stack trace problem!

For completeness, if you run our example code under .NET Framework 4.5, which has a native support for async / await, you get a similar output, telling you all you need to know about the exception:

    at WpfApplication1.MainWindow.<DoSomethingAsync>b__3() in c:\Data\SkyDrive\Development\Projects\Test\WpfApplication1a\WpfApplication1\MainWindow.xaml.cs:line 47
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at WpfApplication1.MainWindow.<DoSomethingAsync>d__5.MoveNext() in c:\Data\SkyDrive\Development\Projects\Test\WpfApplication1a\WpfApplication1\MainWindow.xaml.cs:line 45
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at WpfApplication1.MainWindow.<Button1_Click>d__0.MoveNext() in c:\Data\SkyDrive\Development\Projects\Test\WpfApplication1a\WpfApplication1\MainWindow.xaml.cs:line 34

That is - the good new is that it has been fixed in .NET Framework 4.5.

Monday, November 11, 2013

Accessing awaited decimal array’s item leads to Common Language Runtime detected an invalid program

While converting one of our products to use the async mechanism I discovered a strange .NET Framework behavior.

Suppose you have a following code in your command button:

decimal xyz = GetData()[0];

Let’s say the GetData implementation happens to be resource intensive which causes your UI to be unresponsive when the button is clicked. To fix this, you will convert the method into an awaitable one, such as:

public async Task<decimal[]> GetDataAsync()
{
return await Task.Run(() =>
{
// This would be something that takes a long time to return
return new decimal[] { 1, 2, 3 };
});
}

Finally, you will change your invocation code in the command button to:

decimal xyz = (await GetDataAsync())[0];

Once you compile and run the code, it will produce System.InvalidProgramException exception stating that Common Language Runtime detected an invalid program.

After some investigation I found out that the issue occurs only if ALL of these conditions are met:

  • You are using an array
  • The array is type of decimal
  • You want to await the result and get an item of the array in a one-liner

That being said, if you modify the example above into using an array of int for example, the exception will not be raised and everything will work as expected.

Similarly, if you split the invocation code in two lines, the error will go away as well:

decimal[] abc = await GetDataAsync();
decimal xyz = abc[0];

Even though I agree that this code is much clearer than the original one-liner, the reason why the original code fails to compile remains a mystery to me. A possible bug in the .NET Framework?

Additionally, further testing revealed that this issue is present in .NET Framework 4.5, 4.5.1 as well as in the Async Targeting Pack for .NET Framework 4.0.

The code won’t fail on compilation time, but only on run time, when the async code is compiled on-demand, so watch out for this one!

Monday, June 11, 2012

Removing the remembered login and password from SQL Server Management Studio 2008 R2

Would you like to delete the past logins in the Connect to Server dialog window (shown below) of SQL Server Management Studio? Just delete the SqlStudio.bin file located in C:\Users\%username%\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell.

SNAGHTML241313

Wednesday, November 25, 2009

Outlook will not remember password for Exchange (revisited)

I blogged about this issue a couple of weeks ago. Initially, the solution I described in the article worked for me on my two computers running Windows Vista.

Recently I had a need to do a similar setup on different machines, running different OS versions. Unfortunately, it did not work.

After googling for a while I found a solution and I started using a free Outlook AutoLogin tool from Gabriele. I never had a problem since. The tool can be downloaded at his website http://www.mondada.net/gabriele/autologin. It works with Outlook 2007 and I tested it on Windows Vista as well as XP.

German DevCon 2009 in Frankfurt Am Main

DevConIt was November in Frankfurt again. The traditional time and place for another year of the German Visual FoxPro and SQL-Server & .NET developer conference.

Just as every year, there were many proven German speakers as well as foreign ones, bringing the news from abroad. Among the well known foreign speakers who accepted the invitation for this year were Ken Levy, taking the Keynote again, Doug Henning, Craig Berntson, Kevin McNeish and Rick Schummer. There was also a new speaker from Holland, Boudewijn Lutgerink, a nice guy I have already had a chance to meet at the conference in Prague earlier this year.

Again, there were three days full of sessions. They started in the morning and continued to the evening in the form of late night sessions. As usual, there was plenty of choice available as there were always four sessions running in parallel.

Unfortunately, there has been an inter-annual drop in attendance of 12%. That is a smaller drop compared to the last year, however still quite a high number. The cause of this is apparent. The usage of Visual FoxPro is thickening worldwide as well as the present cost cutting in many companies affects the number of conferences their employees are allowed to attend.

As for the next conference, it will again take the whole three days, but instead of the four tracks, there will only be two. The first one will be targeted primarily at Visual FoxPro development, while the second one at the surrounding technologies and new trends. At certain times, there can be three sessions running in parallel, while those will mainly be the vendor sessions.

As the number of the tracks goes down to two, there will no longer be a guarantee of an English session running at any given time in the schedule. This in fact means that if you understand only English and would like to attend the conference anyway, there might be times to take a break and get some snack for example.

The conference tracks will take a form of a kind of “deep dive” sessions, meaning the given topics will be divided into more consecutive sessions. This will allow the speaker to grasp the topic in a much deeper detail. At the end of the conference, each attendee will also receive a certificate to confirm they have has undergone the given sessions.

Now, coming out of the next year conference topic, Rainer Becker, the organizer of the event, announced that a Visual FoxPro road show is being planned. He also revealed names of the cities. The road show will stop in Hannover, Cologne, Frankfurt, Stuttgart, Munich and possibly also in Zuerich and Wien.

The German user group will also undergo changes. Its name will change to dFPUG.NET. The two conferences, the VFP and the SQL & .NET conferences will merge into one, the 17th year conference.

There were many interesting and inspiring sessions at the conference and I have very much enjoyed being around again. To learn more about the event, please visit its official UT Coverage report, I have had a pleasure of writing again this year.

Friday, November 13, 2009

Outlook will not remember password for Exchange (Windows Vista)

A couple of years ago I started using Exchange hosted email service. The primary motivation for me was the ability to synchronize all the contacts, calendar and task with my new PDA as well as have the instant email push service.

My Exchange server is part of a different domain and I am always connecting to it through the internet. Therefore every time I start Outlook it always asks for the credentials to the Exchange server. I could not find any option to remember the password so I kind of started living with it and supplied the password each time Outlook asked me to.

clip_image001

Yesterday, for some reason, I started figuring out how to get rid of this. And I found a solution.

Basically, there are two types of authentication - a Basic authentication and an NTLM authentication. If your Exchange provider supports only the Basic authentication, there is actually no way of forcing Outlook to remember the credentials. The only workaround I have found is to create an application that would fill in the password for you once the credentials dialog shows up. Cumbersome, but it works. When searching the web, I found a couple of such programs, so you can use those if you like.

If you can use the NTLM authentication, you are a bit closer to a “cleaner” solution. When you use it, you will notice that the credentials dialog has the Remember password option. There is no such option with Basic authentication. Nevertheless, it does not work as one would expect. If you enter your credentials, tick the Remember password option, Outlook will prompt you again next time you start Outlook anyway.

clip_image003

Why? Well, the explanation lies with the fact, that the exchange server basically has two sides. It is the front-end server side, communicating with its clients over the internet and the back-end server side, being in the internal domain. You have to have to be authenticated to both, but sadly, the credentials you entered, and Windows saved, belonged only to the back-end server.

So, now, when we know where the problem is, how do we fix it? To force Windows to remember the password for both servers, you have to enter them manually. Just go to the Control panel -> Users and there you should see an option Manage network passwords (sorry for not being exact, I am translating from Czech Windows).

Once you get there, remove the previously remembered password for the back-end server and add a new entry. The entry should look as *.domain.com, DOMAIN\UserName, yourpassword. Now, if the domain of your back-end and front-end servers is the same, that is domain.com, Outlook will never ask for your credentials again!

You can find more information about this issue on http://support.microsoft.com/default.aspx?scid=kb;en-us;820281.