Sampy's Blog : Visual Studio

Day 4 and 5 - Back to fixing

misampso — Fri, 18 Mar 2005 23:09:00 GMT

Sorry I missed you guys yesterday, we had a St. Patty's day party in the afternoon (my usual blog time).

I spent most of yesterday and today just fixing away at some bugs. I only have 2 right now that are marked as fixed available (I've got the code but I haven't checked in yet):

ClickOnce Automation: BootstrapperEnabled property throws a COMException when accessed
Cannot Undo/Redo dialogs on Publish Page

Did you guys know that the project designer supported Undo/Redo? Most people don't. Check it out (but not the security page, the fix to get it working with the undo redo engine won't make Beta 2).

My brain is pretty fried on code right now so I think I'll work a little on some test driven development stuff until my head clears.

Dark - Day 1

misampso — Tue, 15 Mar 2005 01:50:00 GMT

Fixed 3 bugs today, not bad. I spent most of the afternoon banging my head up against a build problem having to do with my Win Forms designer created resx files. If I can't get it going in the next hour or so, I'll probably just work with my team tomorrow to get it fixed.

Today's Bugs:
Publish Property pages should be disabled when the output type is changed to a non-publishable type (like class library)
FxCop Violation: The ResolveKeySource MSBuild task is too complicated
Signing Property Page UI clean up (the divider lines look wrong)

Do you like this sort of day by day, blow by blow account of my day? You find it interesting? Let me know!

Gauntlet - Measuring success one checkin at a time

misampso — Mon, 14 Mar 2005 18:23:00 GMT

On the VB team, we don't checkin to our source control system (Source Depot or sd) ourselves like mere mortals, we use the automated checkin system called Gauntlet. Gauntlet runs as an .hta app that collects your unsubmitted changelist, asks for some information for the checkin email it will send if things go well, and the bugs it should close in our issue tracker (Product Studio or PS). You run the app from inside our build environment so it has all the right environment variables and stuff it needs to collect you change. After it gets all this data, it uploads it as XML to a server where you wait in the queue.

Once your job gets picked up, it is passed to a build machine which builds your fix and outputs it to a known path on that machine. The controller machine then picks up those changes and puts them on a public share and instructs the test machines to begin. These machines pick up your private fixes and run a pre-defined set of tests you picked when you submitted the job to Gauntlet (you pick what sub-team you work on and it runs all of those tests). If the tests pass, your code is checked into the depot, the bugs are resolved, and the checkin mail goes out (woohoo!). If the tests fail, you get mail indicating which suites failed, what build flavor (debug or release, checked and retail in our language), and links to the logs output by the tests.

When I got in this morning I got a bunch of suite failure mails for 2 checkins that I started over the weekend. Shortly after I parsed through all of them, I got a mail from our Gauntlet admin letting me know we had some machine issues and that's why all the suites failed. Thankfully, it's easy to re-activate a failed job through Gauntlet's web UI. Unfortunatly, I'll be at the back of a long line :P

Going Dark (almost)

misampso — Mon, 14 Mar 2005 17:52:00 GMT

This week VB dev is "going dark" to fix bugs. This means we shut our doors, turn off Outloook, and get some real work done. We've peeled off Beta 2 and are working hard to drive down RTM bugs. By this point in the paragraph, you're probably thinking that I'm going to excuse myself from blogging for a while.

Wrong.

My blog will remain (an become more frequent) as my sole ray of light in this dark time. I'll write about bugs I'm fixing, other things I'm doing, whatever.

Hopefully, I can create a unique view of MS crunch time. We'll see :)

Converting to MSBuild

misampso — Fri, 25 Feb 2005 01:05:00 GMT

So I've spent the last few days devoting my spare time to moving the build process for the DLL that I work on (Micrsoft.VisualStudio.Publish.dll) to build with the new MSBuild rather than Build.exe (our current build system). I have to say that I love MSBuild! Here are the advantages I've seen so far:

My project file is much more readable. Before, our combination of sources file and makefile.inc was difficult to read unless you knew all the macros and properties and what they did. With MSBuild, I have a nice, easy to read XML file which is much easier on the eyes (and gets syntax coloring too).
I can use Visual Studio! I can open my project with Visual Studio, press F5, and start debugging a new VS instance with my changes built and copied to the right place. This is such a huge benefit over the old system of edit, tab to console window, type build, wait, double click VS icon, attach, repeat. All of that is now in one button and I love it.
I can write Unit Tests with Visual Studio. VS 2005 has great Unit test integration and now that I'm fully functional in VS I can write take advantage of all of these features. I can also use the Object Test Bench, the Class Diagram, etc. This rocks!

As you can tell, I'm very excited about this :) The conversion was easy too. The MSBuild team has a dogfood group that has written tools that automatically migrate a good chunk of your sources and makefile.inc macros to a project file. My favorite tool is BuildWatch. You point it at your directory and it builds first the old way and then the new way and lets you compare outputs. It helped me track down quite a few errors in my project file.

I think that one of the best features of MSBuild is that we've created a single format that works in VS as well as from a command line in a build lab environment. You can customize your build with your own tasks or just tweak the existing process; it's all in XML so it's nice and open. VS even guards you from malicious projects so you don't get burned when you download a project from the internet (kind of like macro protection for Office documents). This has to be one of the coolest unsung features of .Net 2.0 (the command line stuff ships with the SDK).

DevDiv is in Ask Mode

misampso — Wed, 16 Feb 2005 18:34:00 GMT

Oops, I meant to metion this when it happened but we entered Ask mode last Monday. We've also forked our code base to a new Beta2 branch that has started producing builds. This means that my branch will soon be available for checkins for RTM which is nice. I've got about 10 or so bug fixes backed up on my machine waiting to go in.

While Ask mode is the last phase of the cycle from my end, I'm not at liberty to say (mostly because I don't know) when the actual Beta2 release date is. "When it's done" has become a popular phrase of late (World of Warcraft, Gmail, etc.) so let's go with that.

But Sampy, what is Ask mode? This is.

Edit: Scooped! I need to pay more attention.

What is Monday?

misampso — Wed, 19 Jan 2005 18:06:00 GMT

I made mention on Channel9 that I'll have more free time come Monday (http://channel9.msdn.com/ShowPost.aspx?PostID=35544#35544). This lead some to think that Beta 2 would be done and I could move on to RTM.

Ha! I wish.

When you get closer and closer to shipping a product, you need to start looking at your bugs and saying: "Is this worth slipping my release?" and "How much instability will this cause vs. the potential gain for the customer?" This kind of cost vs. benefit analysis has been going on for a while in triage meetings (you can see an MSBuild meeting on Channel9 (http://channel9.msdn.com/ShowPost.aspx?PostID=26641#26641 )) but as we get closer, these team level triage meetings grow to division level meetings known as ship room. While a few people on your team run triage, the people responsible for shipping Whidbey run ship room and they can be a bit more intimidating :).

Ship room first comes on to the stage during "Tell" mode. In this mode, your team sends representatives each day to ship room to tell them what bugs your team has decided to fix and why. This gets everyone on the same page when it comes to deciding what bar we use to decide what to fix and what to punt to the next release. If you're fixing too many, you'll hear about it from those scary people I mentioned earlier. Each team is still in control of what fixes they take but they have to now make these choices in a more public forum with the knowledge that things are only going to get stricter.

After some time in Tell mode, we enter Ask mode. Ask mode works the same as Tell mode in some respects: everyday someone from your team goes to ship room with a list of bugs. This time, however, instead of telling them what you want to fix, you have to ask for permission to fix them. Ship room now has veto power over every bug fix in the division. Now usually they'll accept a bug but they also usually grill the team over it asking why it wasn't caught sooner or if it's really as bad as the team thinks it is. As Ask mode goes on, the bar for what gets fixed gets higher and higher. Most teams have been in team level Ask mode since the beginning of Tell mode so a bug has to be pretty bad to make it this far. The division stays in Ask mode until we ship, over seeing each and every bug fix along the way.

There is another milestone that is orthogonal to this idea of Ask and Tell and that is Visual Freeze. After the Visual Freeze date, all bugs that effect UI (GUI or error messages) become Ask level bugs. Remember, we ship Visual Studio in many languages and the .Net framework in many more. That's a lot of money spent on translation. Also we have to ensure that screenshots taken for books and help docs are accurate. When we make last minute changes, that costs a lot of money so only the most dire of fixes make it in. At some point, you've got to stop tinkering.

So I've managed to make it this far with out telling you what Monday is; pretty slick huh?

Monday is the beginning of Tell mode and the Visual Freeze cut off date. Beta 2 inches ever closer.

ClickOnce in Express!!!

misampso — Fri, 29 Oct 2004 08:31:00 GMT

Shout it from the rooftops! ClickOnce is in Express!!

Grab the new October Tech Preview (VB edition http://lab.msdn.microsoft.com/express/vbasic/, scroll to the bottom and click the first link under headlines). Of course, considering that we are still fixing bugs on this internally (it mostly works now) don't be surprised if it's not perfect but at least you know it'll be there! It should work great in our next Beta release.

Once our bug load calms down (have to hit zero by next Friday, of course we'll bounce back up) I'll do some more posts about what you can and can't do as a hobbiest with Express and ClickOnce. Short story: apps that run with the Internet zone permissions are your friend.

What I'm up to

misampso — Thu, 09 Sep 2004 18:09:00 GMT

So we're pushing to get Whidbey out the door so I figured I'd take this chance to let you know what I'm doing to make that happen:

Re-vamping the signing property page: Should be a lot more approachable now
Completing threat models: I only own one model (Use of X509Certificates in ClickOnce deployment) and it's my first so I home I do well. The threat modeling tool we have rocks and I'm pretty sure we've released it to you guys. I'm pretty busy now so if someone does find it, post the link in the comments.
Fixing Bugs: I have a TON of bugs, I think the most on my team. This is mostly due to DCR work that I was doing recently so my bugs have been piling up. Also, I own a lot of UI so there are a lot more nit-picky yet important things that I get bugs on like accessibility and LOC. They are some of the hardest to fix but also key to making sure everyone can get the most out of Whidbey.
Reading Object Thinking: Great book that's really making me think about design in a new light. Of course, not the best book to be reading when closing down the product as it fuels my urge to refactor.

As each day goes by, Whidbey gets cooler and cooler and I can't wait to get it to you guys in Beta, Tech preview, or release form!

The Hosting Process

misampso — Wed, 18 Aug 2004 04:02:00 GMT

A team mate of mine is new to the blog world and has posted a great piece on the new VS hosting process. Check it out!

I actually helped prototype the hosting process when I was an intern 2 years ago. When I wrote it, it was an out of proc COM component and now it's a managed exe that does a lot more than my prototype ever did (though it did get a 5 second perf improvement).

Quickies

misampso — Tue, 03 Aug 2004 17:48:00 GMT

First, I got an email asking if ClickOnce supports passing of command line parameters in the URL query string. The answer is a definitive maybe.

Your manifest will have a flag in it specifying whether or not to trust those URL parameters. If it's set to true, your app will get anything sticking off the end of the URL but if it's false (the default I believe) then ClickOnce will not pass them to your app. The UI doesn't support adding this option in Beta 1 but we're probably going to add it in Beta 2 (I'll probably end up doing it too). So if you want to pass command line parameters, you can.

Second, my post below about ClickOnce in Express using MSBuild got a trackback to a Japanese blog. Now my Japanese is a bit rusty (I studied there for a semester and minored in it in college) but it looks like he translated my post into Japanese! Pretty sweet!

???????????????????????????????Express?ClickOnce??????

Translation: Thanks UnyoUnyo! Now people who read Japanese can use ClickOnce and Express.

Signing Assemblies in Express

misampso — Mon, 02 Aug 2004 17:25:00 GMT

In higher SKUs of Visual Studio, there is a signing property page that is used for signing the assembly as well as your ClickOnce manifests (it's pretty lame in Beta 1 but I just finished rewriting it for Beta 2 and it's pretty sweet). Unfortunatly for express users, they don't have this property page.

Fear not, MSBuild to the rescue. If you know the property names and values that the build tasks in Microsoft.Common.Targets uses then you can strong name sign assemblies in VS and even generate ClickOnce manifests (see my earlier post on this). Here are the magic properties:

Also, you can delay sign with: <DelaySign>true</DelaySign>

Put these in the first property group of your .vbproj or .csproj file and build using msbuild.exe <project file>. Just as a warning though, there may be issues with Express editions not preserving hand edited properties (I have a bug assigned to me to figure this out but it's kind of old so it may have gotten fixed without me knowing) so you may have to edit these manually each time you build. We're considering offering the signing property page in Express in Beta 2. If we decide to include ClickOnce (also under consideration) then we'll probably add some kind of signing property page since you need to sign ClickOnce manifests for them to be valid.

ClickOnce in Express (kinda)

misampso — Mon, 26 Jul 2004 20:39:00 GMT

Okay, time to catch up a bit.

This last week I've been working on a DCR (fixing up the signing property page) so I haven't had time to blog. Now that it's finished, I'm going to make up for lost time and get two quick blog entries out there.

ClickOnce isn't available in the Express version of VS. This means that you won't be able to right click on a project and hit "Publish" and step through a nice wizard and have VS push your app out to a remote server. However, the generation of the ClickOnce manifests is part of the MSBuild system and is available to anyone with the .Net framework installed. You can take an Express project and use MSBuild to create the manifests you need to use ClickOnce today. Here's how you do it:

Create a Strong Name key. Using the sn.exe utility that ships with the .Net framework, create a .snk file. You'll need this to sign you ClickOnce manifests. Put it in the same directory as your projects (better yet, add it to the project using the solution explorer).

Open you project file in notepad. Close your Visual Studio instance and open your project file (the .csproj or .vbproj file). We need to add some new project properties to your project to enable the ClickOnce manifest generation when we run your app through MSBuild. Find the first PropertGroup tag and add the following tags:

<InstallUrl>[where your app will be installed from]</InstallUrl>

The first property will do what it says: turn on manifest generation. The second property is where you want your app to be installed from; this will be placed in the manifests you generate and it can be a UNC path or a web URL. The final property is the path to the snk file you made in step one. The path can be absolute or relative to the project directory.

Run MSBuild. Open a command prompt and cd to the directory of your project. The MSBuild executable is located in your framework directory. For most people, that’s at \Windows\Microsoft.Net\Framework\v2.[your version]\msbuild.exe. Type that path into your command prompt then add the command line switch /target:publish then the name of your project file. Hit enter and watch it go. When it's done, a new directory named publish there in your project directory that contains everything you need to use ClickOnce with your app.

Xcopy to your server. Copy the contents of that directory to the location you specified in step 2. Send the link to your friends (they'll need the .Net Framework 2.0 Beta 1 first though) and get going!

There are a couple of issues you'll need to keep in mind, however. First, there is a known issue where when you load that modified project into Visual Studio, we lose the ClickOnce properties when you save. You'll have to re-add them manually. Also, the manifests you create are strong named signed and ClickOnce will block the install of strong named signed manifests that request full trust permissions (like the ones we're making here) over the internet in Beta 1. We're working on ways for small shops to use ClickOnce over the internet in Beta 2 but the best way to get things going in Beta 1 is to zip up the files and place that zip on the internet and your users can download the zip, unzip it, and install the app. You'll still get all the benefits of ClickOnce updates and app management.

Leave your questions and comments below!

Blog more!

misampso — Fri, 09 Jul 2004 21:16:00 GMT

So my post yesterday was the first one in a long while. I've been pretty bad about this blog thing since I started but this year is going to be different.

As you've probably read from other bloggers here at MS, we've recently gone through our review process where we create commitments for the next year (used to be goals but we've changed that; I took a 20 minute video training that explained the difference and I still think they're basically the same). One of the goals I set for myself was to blog more and to make those blogs more relevant technically. I'm shooting for one good technical post (like yesterday's) a week along with a high volume of smaller posts where I talk about things that are going on here on my team or in the world of technology.

Of course, community is about communication so what would you guys like to see me blog about? I work mostly in deployment but I also dabble in the new project designer, new VB .Net features (99% of the code that I write here is in VB), as well as new framework features like generics.

Let me know what you think!

Everett Bootstrapper

misampso — Tue, 09 Mar 2004 17:37:00 GMT

I'm sure many of you have seen this but those of you with redistributable woes should check out the VS 2k3 Bootstrapper. Think of it as a very limited preview of what you'll be able to do in Whidbey. This will let you let you bootstrap the .Net framework and MDAC only while Whidbey's will let you bootstrap anything you want (if you write the right XML files). I have some time free today that I'm setting aside to finish my post about the generic bootstrapper and post a setup project FAQ.