Vlad Hrybok's Tech Notes

It's much easier to read large numbers when thousands are separated by commas. But I can never remember how the numeric format with thousands comma-separated is defined for .NET String.Format() method and for the databinding. So more as a note to self, here it is:

string output = string.Format("{0:#,#}", 123456789); // Will produce 123,456,789

The same goes for data binding data sources to data controls like DataGridView. Specify format as "{0:#,#}".

I went through the exercise of setting up Microsoft Team Foundation Server 2008, and needed to do group-level-only rights assignment, so that IT folks could manage security by simply moving people in and out of the Active Directory groups to grant/revoke TFS access rights, instead of setting up individual user rights in TFS, Windows Sharepoint Services and Reporting Services. Initially I created some groups for TFS with the "Domain local" scope, which allowed me to nest other, "Global", groups in them. But I noticed that with WSS and RS, assigning rights to "Domain local" groups does nothing - WSS and RS act as users are not members of the group, while TFS services were working properly. I had to re-create AD groups and make them of "Global" scope to make WSS and RS working properly.

After I have upgraded the motherboard on my desktop, a few things got messed up, the most annoying of which was that Visual Studio 2008 has lost its XSD/Dataset editor. Opening a data set resulted in opening it as a text or XML, and when I right-clicked the XSD file and selected "Open With..." from the menu, the XSD editor was not there. Repairing and completely uninstalling and reinstalling VS 2008 did not help. After searching the web I found that some people have the same problem, but I found no solution for Visual Studio 2008. The solution that worked for me was described for the similar problem with Visual Studio 2005. I ran “devenv /resetsettings” and it didn't help. Then I ran “devenv /setup” and hallelujah: XSDs are opening again in the Design mode! To launch devenv you will need to start VS 2008 command prompt first.

After installing Visual Studio 2008 on a new machine and starting playing with a simple Windows Communication Foundation project, I attempted to change service's WCF settings using WCF Service Configuration Editor utility (SvcConfigEditor.exe). However, I got the "Windows SDK is not installed correctly" error. "Internets" were surprisingly mum on the subject, so I had to figure out the solution myself.

To fix the problem, I had to install Windows SDK 6.0 manually. After I did that, the problem went away. Just quit Visual Studio 2008 before installing Windows SDK.

Update: Even after reinstalling Windows SDK, first time right-clicking on the web.config in the Visual Studio '08 Solution Explorer does not bring "Edit WCF Configuration" item to the menu. However, after I did Tools | "WCF Service Configuration Editor", "Edit WCF Configuration" item started showing up upon right-clicking the .config file.

When ASP.NET 2.0 and Visual Studio 2005 came out I hoped that ASP.NET themes will be developed en masse by third parties and sold like those on TemplateMonster.com. Today, tired of ugly GridViews in my apps, I decided to find an ASP.NET theme for at least a GridView, but to my surprise, the only thing I found was this, which is not even a skin. There are millions of sites, books and blogs telling how to make themes in ASP.NET 2.0, but it looks like market for third-party templates has never materialized. Given how fierce the competition in the graphics & UI design world is, I wonder why everyone is missing a chance to take this niche. Microsoft has a few starter themes, but just a few and without live test-drive sites - one has to download and install Visual Studio plug-ins and build the site to see it in action. All this is very strange: it's hard to believe there is no business model in making skinnable themes for ASP.NET applications.

After downloading and installing just-released Visual Studio 2008 on Vista x64, I got compilation error while trying to build the "Hello, World" application. The error was "fatal error CS0014: Required file 'alink.dll with IAlink3' could not be found."
It seemed to be a fairly common error during the Beta cycle of the Visual Studio 2008, but apparently it was not fixed - at least not for the 64-bit version of Vista. Similar to 32-bit versions, the solution was to install two Windows Update items found on the Visual Studio 2008 DVD in the "<dvddrive>:\WCU\dotNetFramework\dotNetMSP\x64" folder (for 32-bit version look in the "<dvddrive>:\WCU\dotNetFramework\dotNetMSP\x86" folder):
1. NetFX2.0-KB110806-v6000-x64.msu. Run it, wait forever, reboot when it's done.
2. NetFX3.0-KB929300-v6000-x64.msu. Run it, wait forever, reboot when it's done.

After those two updates were installed, the problem went away.

CodePlex.com - a relatively new open-source collaboration platform from Microsoft that came to replace old and cranky GotDotNet - has impressed me quite a lot. Of course it closely resembles SourceForge.net, with the main difference of CodePlex being underpinned by Team Foundation Server (TFS) for source control and issue tracking functionality.

People often don't realize that TFS client that integrates into Visual Studio 2005 can be downloaded and is completely free.

I currently host a couple of projects on Codeplex:

• MS AJAX 1.0 Setup Project Prerequisite for Visual Studio 2005.
  It makes MS AJAX redistributable by including it into the Setup.exe bootstrapper prerequisite manifest. The prerequisite integrates nicely with Visual Studio 2005.
  
  
• Simple ASP.NET 2.0/C# MP3 Player.
  This application demonstrates a possibility of building a web application for home users. It includes redistributable UltiDev Cassini Web Server for ASP.NET 2.0 to not make the application dependent on the presence of IIS on users machines. The app is AJAXed to minimize music interruptions and uses Flash player to playback MP3 to avoid dependency on any particular media player. 

Recently I've been working on the small ASP.NET 2.0 app that has a page containing Macromedia (now Adobe) Flash object. When I tried debugging it with Visual Studio 2005 and its internal web server, the Flash piece has never been loaded by Internet Explorer - I am not even sure whether it was the Flash player that failed to load or the .SWF file. I wonder if anyone else had this issue. I could not check which component was not loaded because WebDev.WebServer2.exe serves only local applications, and I could not use an http tracer to see which request gets stuck.

I worked around the issue by switching to our own UltiDev Cassini for ASP.NET 2.0 for application debugging. It served all the bits and pieces required by Flash without a hitch.

Here's how it works: for the last two years we at UltiDev LLC work mainly on HttpVPN - our flagship product and the main reason why our company exists. Once upon a time we've decided that making a simple redistributable web server software would be a great value-added piece completing HttpVPN offering and allowing us to probe prospective market for HttpVPN, gather contact information of people who may by interested in HttpVPN and setup our QA, build and release processes along the way. The experiment turned out to be as successful and we hoped it would be. We've got about 15,000 (and counting) installed UltiDev Cassini Web Server runtimes worldwide and we are receiving overwhelmingly positive feedback from users. All this also means that about every six months we have our Cassini task tracker full enough to suspend HttpVPN work for a few weeks and do another release or UltiDev Cassini. This time was no exception.

Although we always hope to keep our Cassini mid-version upgrade development cycle limited to three weeks, it took us usual five weeks to fix, test, fix again, test again and release the latest version of UltiDev Cassini Web Server. This release had two main points of focus: to eliminate all known installation/registration hurdles and to make UltiDev Cassini compatible with all 64-bit Windows platforms. 64 bit OSes are gaining popularity very rapidly thanks to the fact that most of the recent (and even not so recent - think Pentium D) CPUs from AMD and Intel are x64-compatible. Windows Vista comes in 32- and 64-bit versions right from the start, while existing Windows XP Pro x64 and Windows 2003 Server 64-bit were somewhat obscure because they were released before 64-bit CPUs hit the mainstream. Nowadays it's pretty much impossible to buy a CPU that does not have x64 compatibility. Hoping to please Vista 32 and 64 bit users we made sure that our latest version of Cassini runs smoothly on all the latest multicore 32 and 64 bit CPUs and supports entire (reasonable) line of Windows operating systems: from Windows 2000 to Vista.

Now, whether you own an older version of our tiny but powerful UltiDev Cassini, or you never tried it - go ahead and download the latest version. If you owned old version - most of the known issues will go away (or if you had none you will be less likely to face issues in the future). If you never saw our Cassini - it's a perfect time to spend 20 minutes on something you probably will go "wow!" about. Check it out now!

All! If you use Visual Studio 2003 or 2005 to create MSI-based setup packages, here's a good one for you: if your installation uses Uninstall and Install/Commit custom actions implemented as an installer class - you are in trouble. In the process of upgrading your product MSIEXEC.exe first loads an assembly with Uninstall custom action implementation - to complete previous version uninstallation. After that it tries to load installer class of the new version to do Install and/or Commit custom actions of the new version. At this point things can get really bad. If your custom action assembly is not signed/strongly named (and in my experience sometimes even if it is signed) MSIEXEC.EXE will fail to load custom action assembly from the new version and will run Install/Commit custom steps from the old one. This means that if you added new code to your Install/Commit steps it simply won't be executed during upgrade. Even worse: Install/Commit custom actions of the old version will run instead of the new one!

This happens due to completely bizarre, to put it mildly, logic of .NET Assembly.LoadFrom() method. .NET Framework has a rule that after assembly is loaded it can't be unloaded unless it was loaded into a separate AppDomain: appdomains can be unloaded and assemblies can't. Two assemblies may end up looking the same to LoadFrom() if they have the same name even if they are located in different folders or have different versions. So what happens here is this: after MSIEXEC.exe loaded assembly named 'X' to do Uninstall custom step, the subsequent attempt to load assembly named also 'X' from another folder to do Install/Commit step does not happen. But get this: one would expect that if you asked LoadFrom() to load assembly 'X' from folder 'Y' it should either load it or tell you it can't. Instead due to some truly twisted logic, LoadFrom() won't fail if it can't load new 'X' assembly - it will simply return the reference to the one that is already loaded. So much for solving DLL hell problem!

Microsoft knows about the problem since 2004
http://support.microsoft.com/kb/555184/

It didn't, however, fix it yet:
http://support.microsoft.com/kb/906766

They recommend giving unique names to custom action assemblies for each new release. Alternatively they say signing an assembly will make problem go away. I tried signing and in my small test project it made problem go away, but not in the "real" one. I am stuck with having to rename custom action installer assemblies for each release. All Microsoft needed to do is this: force installer to create new appdomain and load old version's Uninstall custom steps assembly there and let it run. After it's done, unload the appdomain and create the new one where you load new version's custom action assembly with Install step implementation. That would make it unnecessary to give assemblies unique names - strong or physical. My understanding is that Visual Studio adds a small shim DLL to the MSI package that loads .NET installer classes from the custom action assemblies. This means they don't even need to wait for another MSI API release to fix it - every new Visual Studio or a even a Service Pack for Visual Studio could have fixed the issue that is still with us more than three years later.