One of the main reasons I make posts to this blog is to remind myself of things I really ought not to forget later. I've spent the last two days battling against one such thing, only to remember that it was something I ran into a year or so ago and I really should have remembered it. So this time I'm writing it down and maybe it will help someone else too...
What I've been working on is building a managed custom action for a Visual Studio setup project which stores some information in the IDictionary instance passed into the custom action method(s).
public override void Install(System.Collections.IDictionary savedState)
{
base.Install(savedState);
// Persist a custom type into the savedState
}
In my custom action method I need to persist the value of a custom type into the savedState dictionary so that it can be retrieved later when the Uninstall() or Rollback() methods are executed. The custom type to be persisted is tagged with the [Serializable] attribute. When the Windows Installer completes it serializes the contents of the savedState IDictionary in SOAP format to a file (with a .INSTALLSTATE extension) in the directory in which the custom action assembly is located. Inspecting this file clearly shows the custom type persisted in the SOAP XML.
The problem comes when the Uninstall() or Rollback() method is executed. When this happens savedState is null and not an IDictionary instance containing the persisted values as expected. Having spent quite a lot of time debugging this it appears that Windows Installer cannot correctly deserialize the SOAP-encoded dictionary contents from the INSTALLSTATE file. However (on Vista at least) Windows installer doesn't report this fact and silently continues, passing a NULL reference to the custom action method.
The problem is caused by the custom type. If values in the savedState IDictionary are all of standard .NET Framework types then deserialization works correctly and a valid IDictionary instance is passed to the custom action. If any one of the values is of a user-defined type then the deserialization fails.
In short, it doesn't seem to be possible to persist serializable user-defined types into the Windows Installer savedState when using managed custom actions. I'm sure I read something about this last time I stumbled across it, but I can't quite lay my hands on the link just now. If anyone knows how to overcome this particular issue and persist arbitrary types in the installer state I really would be most grateful to learn the solution.
del.ico.us | 
Digg It | 
Technorati | 
StumbleUpon | 
Furl | 
reddit
Yesterday I had the good fortune to present to a group of students at the Microsoft SLIDE 7 student developer conference held at Microsoft UK (though I'm not sure the students would necessarily consider it their good fortune...) This is the second in the series of SLIDE conferences (the previous one being SLIDE 5 in 2005) and it was a well attended event with over 100 students from a number of UK universities.
The theme of yesterday's conference was web development. Myself and my colleague Rob Miles were the only two academics presenting, with the rest of the presenters being developer evangelists from Microsoft UK. The students were exposed to a wide range of web development tools and technologies from basic web services and ASP .NET through to Silverlight and Orcas. Those that I spoke to really enjoyed the day and were fired up about some of the technologies they had seen. They were even more fired up about the free copy of Expression Web in the goodie bag they were given :-)
My presentation was in the Advanced ASP .NET track and concentrated on web unit testing and load testing, something for which Visual Studio 2005 has great support. I suspect this was perhaps a little too in-depth for some of the audience but it seemed generally well received so they must have been a polite audience. Talking to people, especially students, at conferences like this is great as we get to talk at length about the technologies. Normally as academics we have to avoid being seen to promote one vendors tools and are careful to teach concepts and principles, not specific technologies. The thing is that we're also developers and we find some these tools and technologies cool and exciting so it's great to be able to talk about them once in a while.
The one thing that really impressed me yesterday was Popfly. I've not played around with Popfly yet though I do have a Popfly account. I was very impressed with what I say - if you haven't already checked it out, Popfly is well worth following up and makes it really easy to create some impressive and powerful mashups. What really impressed me is that you can save out a project generated with Popfly as a sidebar gadget which can plug straight in to the Vista Sidebar. Fantastic!
If you happened to be at SLIDE 7 yesterday you'll find my slide deck attached to this post. Unfortunately I can't publish the code sample as it depends on some code we produced that isn't in the public domain. You can find the other speakers slide decks on Ed Dunhill's blog.
del.ico.us | Digg It | Technorati | StumbleUpon | Furl | reddit