RobMensching.com /Blog
when setup isn't just xcopy

Visual Studio ships the WiX toolset.

Today Visual Studio released the Microsoft Visual Studio Team System code name "Rosario" November 2007 CTP. "Rosario" builds on Visual Studio Team System 2008 to enhance the collaboration between developers and needs of the business, plus increasing application quality and testing support. Now that you've heard the standard marketing pitch, I'm sure you are wondering why I am pointing to a random preview of functionality from the Visual Studio team.

Well, four months ago the Visual Studio setup team approached me to ask if I could help them with that first part of the "Rosario" mission: "enhance collaboration between developers." They had already adopted the WiX toolset as the platform to build the Visual Studio installation package and were now seriously considering shipping the WiX toolset as part of the Visual Studio product. The VS team saw that the WiX toolset enabled developers to collaborate on installation package development and wondered what it would take get the WiX toolset in a state they could release and support for developers around the world.

When Valentina, the Development Manager for the Visual Studio setup team, first approached me about this possibility I immediately had a flashback to when releasing the WiX toolset externally was first discussed. That was 4 years ago when Stephen Walli and Jason Matusow and others were first discussing what open source license we should use to release the WiX toolset under (CPL) and where we should post the code (SourceForge)

At that time, Stephen and Jason asked me if there was any chance that Visual Studio would want to take the WiX toolset and "productize" it. I told them there was very little chance that they would ever do that. Visual Studio already had a solution for building Windows Installer databases (that was and still is very limited) and showed no interest in the WiX toolset. Besides, I argued, "Wouldn't it be an absolute home run if the WiX toolset was released as Open Source then later incorporated into a shipping product?" At the time, I don't think any of us believed it would actually happen.

So when Valentina asked me if I could help out a little bit by providing some guidance on how to work with the community and provide input on what needed to be fixed first, I jumped at the opportunity. Over the last few months, Visual Studio has staffed up a small team that focuses on improving the core WiX toolset, Votive and the Custom Action Library. For example, Peter Marcu, who is best known for his work on the new patching system in WiX v3, is primarily responsible for fixing bugs in the core toolset, integrating new drops of the WiX toolset into Visual Studio and occasionally shows up on the wix-users mailing list to answer questions. There are several others who work on other aspects of the project behind the scenes.

Rather than continue the story of how it came to be that Visual Studio chose to ship the WiX toolset, let me try to answer some questions that I can guess many of you might have.

Q: What version of the WiX toolset will Visual Studio ship?

A: Visual Studio is built on the WiX v3 toolset internally so it is natural that they chose to adopt the WiX v3 toolset going forward. Also, Votive in WiX v3 is better integrated into Visual Studio than the Votive in WiX v2.  For example, Votive v2 uses a custom build project while votive v3 uses an MSBuild compatible project. Since integration of WiX into Visual Studio is (obviously) so important, Votive is where much of the Visual Studio development activity is focused.

Q: Are the code changes made by Visual Studio team being checked back into WiX?

A: Absolutely. One of the key tenets I encouraged the Visual Studio team to adopt was that all changes to the WiX toolset were immediately made available to the rest of the community. They were completely open to that suggestion so you can see bug fixes coming in every week or so (depending solely on how quickly Peter and I get the changes integrated). The team has just been very quiet about their work thus far since "Rosario" was still undisclosed.

Q: Will Visual Studio ship everything that is in the WiX toolset today?

A: Okay, this might not be a question on the tip of your tongue but I did want to point out that "Rosario" will include a subset of the WiX toolset of their choosing. For example, Votive is definitely in but the WiX Nant tasks are very likely not. At this point, the scoping decisions are completely based on how much the test team feels they can verify before "Rosario" ships. One of the hardest remaining "cut" questions is whether pyro and the new patch support will make it for "Rosario". I'd love to see it in but we'll see if there is time to get it stable.

Q: When does "Rosario" ship?

A: I don't know the final ship date (I don't know if anyone knows) but I'm assured it won't be earlier than end of 2008. This was important because I always had in my mind that WiX v3 wouldn't really be feature stable until the end of 2008 and that we'd go into 2009 with bug fixing. With Visual Studio putting a number of developers on the project full time to address the bugs, I am now confident WiX v3 will be good to go by the end of 2008.

Q: Will WiX replace the current Visual Studio Setup Projects in "Rosario"?

A: No. "Rosario" is a very short release so the WiX toolset is being added on top of everything else. The current Visual Studio Setup Projects have a number of visual designers to ease the development of installation packages but does not enable collaboration across developers. The WiX toolset has a steep learning curve but has a number of features that enable different developers to collaborate on one to many installation packages.

Q: Will "Rosario" include any visual designers for the WiX toolset?

A: At this point in time I don't expect there will be any visual designers for the WiX toolset built in the "Rosario" timeframe. Again, this is a very short release and there is a lot of existing code that the test team needs to verify. I expect that the primary output from "Rosario" will be a very stable WiX v3 toolset integrated extremely well into the Visual Studio project system.

Q: Bummer, dude.

A: That isn't a question but the sentiment is shared by a great number of developers on the project. I try to remind everyone that the work in "Rosario" provides a great foundation to do some very interesting work in the next few releases of Visual Studio. So, let's hurry up and get "Rosario" done and move on to those other interesting features.

Q: So what does "Rosario" provide?

A: There are two key features that I believe "Rosario" provides. First, there will finally be a clean "out of the box" experience to build Windows Installer databases (.msi/.msm files from .wxs source code) on your Visual Studio Team Server build servers. There have been a lot of requests for this functionality both to the Visual Studio team as well as those of us that work in the WiX community. Second, Microsoft will provide support for the WiX toolset that is part of "Rosario". Again, I've heard many reports of customers asking for Microsoft to provide support services for the WiX toolset and with "Rosario" their support requests will finally be answered.

Q: Will I still be able to use the community built WiX toolset with Visual Studio?

A: Yes. This was the second tenet I encouraged the Visual Studio team to adopt and they are doing their best to make switching out the "Rosario" WiX toolset with the community WiX toolset a reasonable experience. There are some technical challenges (inside Visual Studio itself) that look like it will not be possible to have both versions installed at the same time. So, the goal is to make it easy to uninstall the "Rosario" WiX toolset and install the community WiX toolset. Since the November 2007 CTP of "Rosario" is shipping as a virtual PC image we haven't tackled all of these issues yet.

Q: How will the WiX toolset in "Rosario" be different than the community WiX toolset from SourceForge?

A: As I noted above, "Rosario" will ship a subset of the WiX toolset so there will be tools and functionality available on SourceForge that is not going to ship in the box. Also, Visual Studio might modify some cosmetic things (like the icons and assembly signatures) so developers can differentiate "Rosario" WiX toolset from the community WiX toolset. Finally, the community WiX toolset will continue to be developed after "Rosario" ships so there are an untold number of improvements we might choose make that won't be in "Rosario". I'll encourage Peter to list any differences between "Rosario" and what is available in the community.

Q: Should I wait for "Rosario" instead of getting VS2008 now?

A: You could but I wouldn't do so for the WiX toolset changes. We've already made the changes (thanks to Aaron) to support WiX on Visual Studio 2008 (that just released, yippee!). That means you can see (and benefit from) the developments made for "Rosario" every week or so on SourceForge. When "Rosario" finally ships then you will have an integrated installation experience and have Microsoft support backing up the product.

Q: So does this change anything in the WiX community?

A: I don't think so. The same set of people still lead the project (myself, Bob, Justin, Peter) and we still hold the same vision: "Create a set of tools that integrate into the development process so all developers can build high quality setup packages."  Now there are a few more developers working full time towards that vision. I couldn't think of a better thing for the community.

 

WiX editors.

I've had a number of people ask me lately if there were any editors for the WiX toolset. This question surprised me because I thought the common WiX editors were easily found in one search query. Turns out neither query really covered the list of WiX editors that I often heard bandied about so I thought I'd write them down here.

I would like to note that this list isn't really meant to be the authoritative list of all editors for the WiX toolset. These are just the list that I've heard people talk about most. Of course, since there are differences between WiX v2 and WiX v3, I've split the list of editors in by version.

WiX v2 editors

• SharpDevelop 2.1 (open source) - is something of an Open Source Visual Studio clone. However, rather than build a clone of the limited Visual Studio Setup Projects SharpDevelop chose to integrate WiX v2.
• Votive (open source) - is released as part of the WiX toolset to provide project integration into Visual Studio. Votive that shipped in WiX v2 is not very feature rich and has stability issues.
• WixAware (commercial) - was the first commercial editor built on the WiX toolset. WixAware tightly integrated their visual designers and text editor so edits in one display in the other.
• WixEdit (open source) - was the first open source editor built on WiX v2 to have a visual designer. WixEdit is unique in that it adapted to the monthly releases of the WiX toolset.

WiX v3 editors

• Setup Factory for Windows Installer (commercial) - was the first commercial editor built on the WiX v3 toolset. The lead developer for Setup Factory participated in the WiX community (by answer other's questions) months before announcing their product demonstrating (IMHO) some appreciation for the community.
• Votive (open source) - is a much improved version of the Visual Studio package provided with the WiX toolset. Votive is far more stable and integrates deeper with Visual Studio, Team System and MSBuild.
• WixEdit (open source) - continues to adapt to the changes in the WiX toolset. The latest version of WixEdit supports the latest versions of both WiX v2 and WiX v3.

I'm sure there are plenty of WiX editors out there that I've missed so feel free to leave a comment down below with links to other quality tools. Finally, in case you're wondering what tool I use to edit my .wxs files, I typically use Votive for large projects or demos and Notepad2 for my day to day tweaks and bug fixes. The same goes for my .cs file editing (Visual Studio for large projects and Notepad2 for tweaks).

 

WiX v3 on the road to .NET Framework 2.0.

A couple weeks ago I sent out a proposal to move the WiX v3 toolset to the .NET Framework 2.0. There wasn't much of a response but those that did were positive towards the proposal. I think most people just assumed that the WiX toolset required the .NET Framework 2.0 already. I also think that most developers have already adopted the 2.0 CLR so the dependency is no big deal. Finally, I also expect those developers still building on the .NET Framework 1.1 are probably using the WiX v2 toolset.

Anyway, tonight Bob and I started the process of going through all the tools that still build for the 1.1 CLR (candle, light, dark, heat, pyro, melt, wix.dll, almost all of the extensions, basically everything <smile/>) and converting their NAnt .build files into MSBuild .csproj files. Technically speaking we could just continue to NAnt but I get continued requests to use MSBuild (everyone has their reasons, the most common being that VS natively understands MSBuild projects) so I figured now would be a good time to do the switch.

Of course, there are some tricky things we do in the WiX toolset (like removing the insignificant white space and comments from XML files before embedding them into an assembly) that are turning out to be interesting exercises to execute in MSBuild. A long while ago, Justin created a bunch of MSBuild tasks for many of the things we needed to do. Unfortunately, tonight we learned a couple of them didn't work. Figures that Justin wouldn't show up tonight as well. <smile/>

So progress is underway. I expect it'll be a couple a another week or three to get done with the holidays coming up. We basically have to do the whole move at one time once we start with wix.dll, since everything is dependent on that assembly. I'll send out more updates when we have them.

 

Model View Presenter links

Some of you may be wondering why I went MIA for for about 8 weeks. Obviously, I got busy. There were two forces sucking up all my time over the last couple months. The largest one was a complete rewrite of the some of the functionality in the digital locker. The existing code base in the digital locker (and pretty much all of Windows Marketplace) is extremely monolithic. As a monolithic block of code it is extremely difficult to fully comprehend, enhance both tactically and strategically and it is completely impossible to unit test.

Since I was tasked with this very large feature modification for the digital locker, I took the opportunity to go out and learn the latest in web application design especially as it relates to UI.  This was vital since I've never really drilled down into UI design and how it should interact with data. You can actually see me starting the learning process back here on August 26th.  It was pretty clear (at that point in time) that Model View Presenter (MVP) was the predominant leader in UI design for ASP.NET based web applications.

Yesterday, I presented my two months of learning about the "best way to design web applications" to my team in an hour+ meeting. The functionality for the digital locker is basically complete and we are into integration testing so I had plenty of code to reference throughout the presentation. Unfortunately, I don't feel comfortable sharing the code with the outside world so instead, I'm going to share the links that I found most useful to learn about MVP and how to use it in ASP.NET based web applications.

Phil Haack had two great blog posts that where at exactly the right level of complexity when I first started.

• http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx - this is a nice overview of how we approached things for the digital locker improvements. We do some of the smaller details differently (for example our Views use an Update method to get data out of the view into the model) but it is a very easy to understand overview.
  
• http://haacked.com/archive/2006/06/23/usingrhinomockstounittesteventsoninterfaces.aspx - this is where I first discovered Rhino Mocks. This has a pretty nice overview. Mocking just takes a little bit of playing with it to really understand it.

At the same time I was reading through Phil's comments, I was looking for more detailed information. Billy McCafferty showed up a number of times and these two links where referenced much as I tried to be understand the minutiae of MVP.

• http://www.codeproject.com/aspnet/ModelViewPresenter.asp - this is a really long article that covers lots of information in depth.  I read this about 5 times before it all started making sense.  The first overview above is a nicer introduction but this has lots of good detail.
  
• http://devlicio.us/blogs/billy_mccafferty/archive/2007/03/19/considering-a-view-s-get-set-roles-with-mvp.aspx - this is where the view’s get/set discussion happens.  We’re attempting to use the View.Update method he describes in this entry.

While I was creating my presentation for yesterday I found the following blog entry. I so wish I had found this earlier.

• http://blogs.infragistics.com/blogs/tsnyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx - this provides a really nice graphical representation of one concept that took me a while time to truly grok.

Those top four links made up the bulk of my reading and re-reading over and over. The following links were stuff I kept being looped back to so reading them is encouraged but I liked the way the information was presented above far better.

• http://martinfowler.com/eaaDev/SupervisingPresenter.html - this is the actual pattern we are implementing.  MVP actually started here:  http://martinfowler.com/eaaDev/ModelViewPresenter.html
  
• http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx - an MSDN article that I never really liked.  It’s worth a read but don’t get too hung up on it.  The stuff above is far better.
  
• Random other interesting pages:
  http://www.darronschall.com/weblog/archives/000113.cfm
  http://geekswithblogs.net/billy/archive/2006/07/20/85815.aspx
  http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx

Now, on October 14th Scott Guthrie announced a new MVC framework for AS.NET. I am extremely excited about what they are doing here because when I first started reading about UI design in ASP.NET it was clear that the "state of the art" was being kinda' kludged into the ASP.NET Page/PostBack system. There were moments when I wondered what it would take to move the digital locker to Ruby on Rails. <smile/>  MVP ended up working out just fine but it is great to see ASP.NET adapting to support MVC and TDD more natively.

Anyway, we have a decent infrastructure in place now. When the ASP.NET MVC Framework is finally released I'll have a hard decision to make about what to do with our existing architecture. In the meantime, there is plenty of work to do and I'm now in position to pursue 95% code coverage with my unit tests (something that was completely impossible before).