Vlad Hrybok's Tech Notes

My Windows Mobile 5 based Cingular 3125 cellphone stopped syncing with Vista desktop quite some time ago. Synchronization error stated "ActiveSync encountered a problem on the desktop", which is weird since Vista has replaced ActiveSync with Sync Center and Windows Mobile Device Center (WMDC). Checking error log on the device yielded reference to "Support Code 0x85010014", but no information on how to contact support. 

Quick brute force "google & fix" approach didn't work, so it was until now that I found time to find the solution. As many articles on Internet point out, Support Code 0x85010014 problem is related to syncing with Microsoft Office Outlook. In my case it was Outlook 2007 running on Windows Vista Ultimate Edition.

Despite legions of people experiencing this problem, it was surprisingly hard to find the workaround. The fix (first mentioned here) turned out to be simple: repair Microsoft Office installation by going to Control Panel -> Programs And Feature, selecting Microsoft Office 2007 and then clicking Change button on the toolbar.

Summary

UPDATE: This sample is an open-source project now.

This article describes how to build a redistributable ASP.NET application that allows users browse remote server's file system and pick folders with MP3 files to be played by embedded Macromedia Flash-based MP3 player.

Article Sources

Download article's C# source in a form of Visual Studio 2005 Solution comprising ASP.NET application and a Setup Project. Unzip the archive to "C:\".

End Result

  

After building the project you will have an MSI-based setup package that can be installed on virtually any Windows-based PC. Installed application will be accessible from inside the LAN as an intranet application without having to install IIS.

Prerequisites

- Visual Studio 2005.
- UltiDev Cassini Web Server for ASP.NET 2.0. UltiDev Cassini is packaged together with the application into the Setup.exe so that the final application would not depend on IIS being present on target system.

Let's Begin (Getting Ducks in a Row)

A few weeks ago I stumbled upon a great piece of free software:Flash-based XSPF-compatible MP3 player. When embedded on a page, it can take playlist over HTTP and play it. Second nice thing was that XSPF play list format has XSD schema available. .NET Framework xsd.exe utility allows easy conversion of XSD schemas into C# or VB.NET classes incapsulating the structure of the data defined by the XSD, as well as implementing XML serialization to and from XML files conforming to the schema. So I had an XSPF-compatible MP3 player and a free code generating XSPF-compatible XML. That meant I could easily create XSPF-compatible playlists on a fly. Only if I had free ID3 tag (MP3 file metadata) access API...

Finding ID3v2 library for .NET was harder than I expected. However search was ultimately successful. The UltraID3Lib ended up being just what I needed. It's a nice library; may be just be a bit over the top object-oriented.

Final piece is UltiDev Cassini Web Server for ASP.NET 2.0. It's necessary because first, it can be packaged and shipped along with any ASP.NET application eliminating requirement for IIS. Second, unlike IIS UltiDev Cassini service works under "Local System" account, which enables access to any local file and folder on the server. One thing to note, while this is quite convenient to have a web server running under powerful account, it may pose a risk if the application is exposed on the web. It's best to work with the application inside protected local area network.

After you have downloaded the solution, unzip it on C:\. It will create "C:\UltiDevMusicPlayerSample" folder. If you want to put it in some other folder - you can do that too - simply adjust your project debugging settings later to point to the correct application folder (see below).

Application Flow

- Application has a single page (Default.aspx) containing the player control and file a system browser (Controls/PlayerControl.ascx and Controls/PlayerControl.ascx.cs).
- After user selected a folder with MP3 files, file system browser tree gets hidden and player control is re-rendered to point to the dynamically-generated playlist representing selected folder.
- Player control requests dynamic playlist and custom IHttpHandler (AppCode/PlaylistClass.cs and AppCode/xspf.cs) serves XSPF-encoded playlist containing songs in the selected folder. Playlist contains song information retrieved from songs' ID3v2 and ID3v1 MP3 tags.
- Player plays songs one by one: requesting each one from the custom IHttpHandler (Handlers/Song.ashx) serving songs from local file system. After song started playing player also requests song album artwork (cover art) from custom IHttpHandler (Handlers/CoverArt.ashx) which serves image extracted from song's ID3v2 tag.

Debugging

I had troubles getting Visual Studio 2005 internal web server to serve Flash component. I switched to UltiDev Cassini for debugging and that has solved the problem. Debugging with UltiDev Cassini is probably a good idea anyway since the application is eventually going to run under UltiDev Cassini.

To switch to UltiDev Cassini, bring up ASP.NET application's properties, select Start Options of the left, and check "Start External Program" radio-button. Enter "C:\Program Files\UltiDev\Cassini Web Server for ASP.NET 2.0\UltiDevCassinWebServer2.exe" as the program to be used for debugging, and specify "/run c:\UltiDevMusicPlayerSample\WebApp Default.aspx 4125" (no quotes) as command line arguments. If you have unzipped solution to a folder other than "C:\", then you will need to modify c:\UltiDevMusicPlayerSample\WebApp part of the command line arguments to point to the actual application location.

Setup Project

Unlike regular ASP.NET application, this application is using regular (non-web) setup project for installer implementation. The reason for that is the Visual Studio web setup project is actually IIS setup project. Since we are using UltiDev Cassini instead of IIS, regular setup project is required instead.

Setup project packs UltiDev Cassini into Setup.exe bootstrapper and ensures application is registered with UltiDev Cassini during installation process and gets unregistered during uninstallation.

Creating a setup project for ASP.NET application bundled with UltiDev Cassini is not complex, but if you need step-by-step guide, please refer to this walk-through.

IMPORTANT: When installing the application, don't just click the .MSI file. You will need to run Setup.exe to ensure UltiDev Cassini web server gets installed on target system. This is especially true on Vista, where clicking .MSI and running Setup.exe are not nearly as functionally close as it used to be on Windows XP.

Build & Enjoy!

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.

In attempt to create a less dry than your usual "Hello World" ASP.NET application to showcase UltiDev Cassini Web Server, I decided to write a simple web-based MP3 player application using Maсromedia (now Adobe) Flash. I was very surprised by how long and frustrating was my search for a free .NET-based API allowing programmatic access to ID3 tags in MP3 files from C# and VB.NET. I started working with something I found on Codeproject.com, but that piece turned out to be buggy beyond any degree of practicality. My second sweep across Internet yielded a much better (if only somewhat over-engineered) solution - the UltraID3Lib. Its UltraID3 class is the starting point of the journey. The library worked out for me very well. Thumbs up.

Think what would happen if Microsoft was giving away Windows for free to everyone, and would also be giving away Visual Studio to developers, but taking %% of every sale of every program ever made for MS Windows. Think of how much more money would they would have made? Could Bill Gates have become  a first trillionaire?

First of all, no worries, I am not a nut who writes another OS. Creating a new operating system is WAY too complicated, costly and most importantly financially risky: OSes are commodity - it's impossible to change the world by creating another OS now.  Instead, I am creating a new platform. What is platform? To give a definition, platform is an operating environment for programs, and a user interface conduit for users. To give a few examples: Internet is platform: back-end web server is an operating environment for programs and browser is a conduit for the UI; every operating system is a platform: Windows, Linux, MacOS – their APIs and drivers form an operating environment and OS desktop and windows is a UI conduit; web browser is a platform too, albeit a limited one – it can run client scripts and therefore it’s an operating environment and a UI conduit at the same time. You get the idea…

Platforms differ in reach and complexity. Operating systems make a somewhat mediocre platform: they have limited reach – contained by the hardware they designed for, by how incredibly expensive it is to make an OS, and by how hard it's to learn to develop applications for a new OS. Adoption threshold for a new OS is very high. Web, on the other hand, is a very good platform: HTTP protocol is insanely simple, web development is relative simple and mastered by ever-growing legions of developers, web is not constrained by hardware, and finally web has a virtually unlimited reach. Curiously, web as a platform is built on top of other platforms - underlying disparate OSes running web server back-end software and user browsers. it’s a platform layered on top of other platforms – OSes.

The drawbacks of the Web as a platform include:

1. Deploying and operating web apps is complex and costly. It is very hard to make an application accessible on the web: all the routers, firewalls, networking, DNS servers, domain names leases, IP addresses -  everything involved in deployment of a web application is much more complex from user’s standpoint compared to regular program with a "pop-in a CD and have it installed" type of deployment;
   
   
2. Web applications are hard to market. From developers’ perspective business models for selling web app is limited to big-ticket sales to businesses who have budget and skills necessary to run web-facing infrastructure.

Now, imagine World Wide Web with above-mentioned problems removed. That is what I am doing: a new web-based platform that has user reach as wide as current Internet, but removes application deployment and marketing hurdles that are limiting web application usage right now. That’s a unique innovation right there. “But hey, there’s more!” Another unique innovation is the business model: I am not going to sell this platform to users, or development tools to developers. All will get it for free. The catch? All software that uses our platform can only be sold and bought using channels belonging and controlled by UltiDev, and like eBay we are going to take %% of every application sale.

You may have some concerns, like will developers find this new platform attractive enough to spend effort learning it and making programs for it? The answer is no, they won’t. Because they won’t need to. The beauty of it is that application developers can take their existing skills and even their already-built applications and simply package them together with our new platform components and ship it to users. Every member of millions-strong army of web developers worldwide is ready to take advantage of this new platform.

You may also wonder how complex is this new platform? Will it take billions of dollars an decades to create it? Well, it’s complex enough to take two years to develop, but the good news is that it’s virtually finished and working pre-alpha releases are deployed. 

Small detail: the platform described above is called HttpVPN™ and some additional technical information is available at http://ultidev.com/Products/httpVPN/.

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.

In Windows XP one could just double-click an .MSI (Windows Installer) file to start package installation: MSIEXEC.exe is associated with the .MSI extension and if user had administrator rights installation would go forward. Clicking .MSI file was functionally identical to running Setup.exe bootstrapper, provided Setup.exe didn't have additional functions other than starting the installation.

In Windows Vista things are different. When Vista's User Account Control (UAC) is turned on, launching Setup.exe is not quite the same as running MSIEXEC.EXE /i mypackage.msi. The difference is that when Setup.exe is started, Vista runs it in "elevated" mode, which gives the process more privileges. MSIEXEC.EXE does not seem to run in elevated mode and therefore behavior of the installation may be different.

The issue seems to be manifesting itself most often when an MSI setup package made using Visual Studio executes custom action steps implemented as an Installer class. I am not sure what exactly happens but I noticed that MSI error 2689, which is a common result of failed custom action, will go away if installation initiated using Setup.exe instead of just clicking on .MSI file.

Bottom line: On Vista always start installations by launching Setup.exe instead of double-clicking .MSI file.

Another possibility to consider: if you were not a victim of computer virus attack in the last five years (Windows XP lifetime), then you are may want to simply turn Vista UAC off.

If it takes too long to redraw the screen when you access your remote virtual machine using VmWare Server Console or Microsoft Virtual Server admin page, consider terminaling into your virtual machines using Remote Desktop or Terminal Server client. UI works as fast as with any "real" remote PC. Entry-level Windows XP Home and Vista Home don't support Remote Desktop, but all Pro, Business, Media Center Edition and other flavors of Windows Vista, XP and 2003 work just fine. One of my co-workers told me Remote Desktop can be used for VmWare Workstation access, but I also tested VmWare Server and Microsoft Virtual Server R2, and those two also do it.

To enable Remote Desktop access a few things usually need to be done:

1. Enable RD access:

2. Ensure your user account is a member of the Administrators group.
3. The password on your user account is not blank.

The only issue I had with this setup was sometimes I couldn't ping the virtual machine due to networking issue. But when that happens all attempts to access that virtual machine over the LAN fail, including NetBIOS file shares, web access - anything.