Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

rwandering.net

The blogged wandering of Robert W. Anderson

2nd Microsoft ISV CTO Summit

I’m coming back from the 2nd Microsoft ISV CTO Summit up in Redmond (I blogged about the first one here).  A good trip with worthwhile content.  I’m not sure any of it was really new, but I did see some cool stuff:

Expression Blend

The tool for designers to design and build WPF projects.  Definitely cool. 

I had two questions for one of the presenters (Eric Zocher) afterwards: when will Visual Studio look as good as blend (e.g., Blend uses WPF and allows smooth scaling of its own UI).  Answer: um, maybe never. 

Since Blend is basically a developer tool (for designers) that can create and edit Visual Studio, does it integrate with TFS?  Not yet.

Of course, these answers don’t take away from Blend at all (and certainly TFS will eventually come even though outsourced designers may get little value from that). 

I’m no designer, but I’m  looking forward to playing with it.  Though they haven’t announced this part yet, I expect it will be made available through MSDN Maximal (or whatever they are calling it now) or through our Gold Certified ISV Competency.

WPF/E

This stuff is very cool.  Actually, Scott Guthrie demoed the WPF/E Vista emulator that Savas recently linked to.  The great thing here is the unification of the presentation story here.  I won’t go further into the roadmap because it is never clear to me at these NDA events what is open knowledge and what requires the secret-squirrel decoder ring.

AJAX ASP.NET

I tracked this as a really good thing (to greatly simplify AJAX for .NET devs), but I hadn’t taken the time to look at it or the demos.  It is really cool.  Aside from all it can do, the coolest thing is how easy you can enable it for existing ASP.NET applications.  I would have tried it out already (i.e., in our Digipede product), but I stayed out too late last night to get into it.

WinFx dead?

I had a chance to ask Scott Guthrie directly about whether the WinFx name change was an indication of the death of the managed Windows API (as I argued here).  His response, basically, naaah.  Just a marketing change.  I still disagree, as long as the managed API rides atop Win32, it isn’t the actual Windows API.  In this case the managed API is either dead or were waiting for Singularity.

Swag

These events always come with some swag.  This time we got a strange floppy neoprene folder (for small laptops here) and what I think is a screen cleaning cloth (though looks like a compressible handkerchief). 

Cheers, though, to Microsoft for not giving us a bunch of junk for the landfill — I include in this: lamps, USB speakers, travel clocks.  Also, I think it is great that they didn’t give us a whole bunch of resource CDs, trials, betas, etc.  Last time they did and these are mostly useless.  Not for the content, but because we all already have this content in MSDN or available through other partner programs.

They did give us one useful thing, though: a Vista Ultimate DVD/license.  Frankly, that is my kind of swag.

Tags: , , , , , , , , , ,

Interested in ASP.NET for your startup?

A question I ask Microsoft people frequently is: what are you doing to promote your tools in the Web 2.0 world / to help SaaS startups use your technologies?
I saw two posts today that, while not answering this question, seem to me like progress:

ASP.NET 2.0 Training Center

Microsoft (and CMP and O’Reilly and Dr. Dobb’s) have rolled out the ASP.NET 2.0 Training Center. This is to help PHP / JSP / ColdFusion developers learn about .NET. This looks like a great resource for developers to learn about the capabilities of .NET. If you are a developer using one of these other technologies, check it out. There is a free copy of Visual Studio 2005 Standard in it for you if you view 3 webinars.

Obviously, this is a great tactic to get non-.NET users to see what ASP.NET has to offer — I’m sure they’ll get plenty of free-riders too ;)

I found out about this from an O’Reilly post (see ASP.Net on a Roll). According to them, ASP.NET 2.0 is gaining leverage (as measured by book sales). Good news for Microsoft and for developers. ASP.NET is really a great way to build Web sites and services. I personally much prefer this to PHP, for example. Scripting languages are fine, but I’m in the strong-typing camp. And now since ASP.NET 2.0 can recompile your code on the server, it takes away a major scripting advantage.

Microsoft Startup Zone

In Microsoft Startup Zone Launches, Don Dodge announces the new Microsoft Startup Zone, sort of a portal into Microsoft’s Emerging Business Team. This site is full of resources for startup companies. While I still would like to see a partner program for SaaS startups, this site is worth a visit if you want to see what Microsoft has to offer emerging companies.

Tags: , , , ,

Visual Studio 2005 Web Deployment Projects AddIn

In Renaming ASP.NET 2.0 Assemblies Redux, I detail a way to handle renaming ASP.NET 2.0 assemblies without aspnet_merge. The release of Visual Studio 2005 Web Deployment Projects (Beta Preview) pretty much obviates the need for my solution (unless you need exact control over your per-folder assembly names). If you haven’t heard about the new add-in (and aspnet_merge), read this Scott Guthrie post for an overview: VS 2005 Web Deployment Projects.

All in all, it seems to work well — thanks to the ASP.NET 2.0 team for getting this together so quickly. I did come across the following (very minor) issues:

  • If I happen to click on the VS IDE while building the deployment project, I get a “Microsoft Visual Studio is Busy” warning in a notification icon ballon.
  • It is cool that you can open the build deployment project without unloading the project (as you do for other project types); however, it doesn’t warn you if you edit the project file and (without saving) then change the properties. It does detect the problem when you try to save the project file, but this is a bit late.

Also, I was looking forward to the ability to replace sections of the Web.config, but found that I basically wanted to replace something in nearly every section. I ended up going back to what I used to do: have two config files stored in my development project: Web.config and Web.release.config. The former is used during development and I copy the latter for use in deployment. An easy way to do this with Web Deployment Projects is by editing the project file and using the MSBuild Copy task:

<Target Name="AfterBuild">
  <Copy
    SourceFiles="$(SourceWebPhysicalPath)\\Web.release.config"
    DestinationFiles="$(OutputPath)\\Web.config"
  />
</Target>

The functionality provided in this addin resolves the issues I had with the new ASP.NET 2.0 deployment model. We get many more choices including the old-style single assembly. Yes, this is more complex than ASP.NET 1.1, but the greater flexibility and benefits of the new model make it worth it to me.

Tags: , ,

2.0 Port Update: Finished (for now)

Now that I am finished with the port to VS2005 / .NET 2.0, I wanted to point out a few final issues I came across. Note that we use the Preemptive Dotfuscator v3.0 here, but the obfuscation issues likely apply to other obfuscators as well:

New files in ASP.NET 2.0

As the compilation model for ASP.NET has changed a great deal, there are also some new files that you must deploy. Of course, this is not an issue if you use VS2005 to deploy directory to a web site, but if you are packaging up all of your files into an installer then make sure you include these new files:

  • *.resx
  • *.compiled
  • PrecompiledApp.config

In particular, I have found that if the *.compiled and PrecompiledApp.config file are not in place, your global events will not get raised.

Obfuscation Issue #1: Don’t rename __ASP

Exclude the __ASP namespace from the renamed. This is a new namespace that is generated by the compiler, so you need to exclude this in your Dotfuscator project file:

  <renaming>
    <excludelist>
        . . .
        <namespace name="__ASP" regex="false" />
        . . .
    </excludelist>
  </renaming>

Note that there is also a new ASP namespace, but I did not have to exclude this one because I was already excluding class names that are automatically placed under this namespace. Obfuscation Issue #2: Don’t obfuscate multiple Web projects at once

Before ASP.NET 2.0, it was possible to obfuscate multiple Web projects at the same time (as long as all of the namespaces are unique across projects). The new namespaces that are generated by the compiler (i.e., ASP and __ASP) will cause a conflict during obfuscation. To solve this problem, you need to break up your obfuscations into multiple projects.

This last part is somewhat non-trivial (or at least a real hassle). I have written many nant scripts that take build output and assemble them into a directory for obfuscation, breaks up the Dotfuscator configuration file, runs multiple obfuscation runs, and finally reassembles the files into individual folders for release.

I am not going to blog on those specifics, but if you are interested in my solutions to these problems, feel free to contact me.

Tags: , , ,

Merging ASP.NET 2.0 without aspnet_merge

Apparently Microsoft will be releasing a tool called aspnet_merge that will help resolve some of the shortcomings in the deployment options when precompiling ASP.NET 2.0 projects. This is supposed to be available on November 7th, but I don’t feel like I want to wait. Thanks to the DotNetNuke guys for working with Microsoft on this. I’m really surprised that it got to be so late in Microsoft’s development cycle before they figured out this was a problem.

I thought I’d try ILMerge to do it. Searching to see if someone else had, I came across this post by K. Scott Allen: Using MSBuild and ILMerge to Package User Controls For Reuse. Similar problem, different goal.

I went ahead and did this with nant as that was the quickest way for me to get this into my release process. I admit this is all a kind of a hack. First, I search for all App_Web*.dll files. Then I replace all references in the aspx and ascx files with a reference to my new merged dll. Finally, I use ILMerge to merge to the new dll. Note that I’m not merging everything, just the assemblies that have seemingly random names.

The nant code follows. It is a bit clumsy, but it works.

  <property name="ProjectPath" value="${BuildRoot}\PrecompiledWeb\${ProjectName}" />
  <property name="ilmergePath" value="c:\Program Files\Microsoft\ILMerge\ILMerge.exe" />
  <property name="mergedAssemblyName" value="ControlMerged.dll" />
  <target name="deploy">
    <property name="assemblyFiles" value="" />
    <foreach item="File" property="assembly">
      <in>
        <items basedir="${ProjectPath}\bin">
          <include name="App_Web*.dll" />
        </items>
      </in>
      <do>
        <property name="assemblyFiles" value="${assemblyFiles} ${assembly}" />
        <copy todir="${ProjectPath}/tmpBak" overwrite="true">
          <fileset basedir="${ProjectPath}">
            <include name="**\*.as?x" />
            <exclude name="tmpBak\**" />
          </fileset>
          <filterchain>
            <replacestring from="${path::get-file-name-without-extension(assembly)}" 
                           to="${path::get-file-name-without-extension(mergedAssemblyName)}" />
          </filterchain>
        </copy>
        <copy todir="${ProjectPath}" overwrite="true">
          <fileset basedir="${ProjectPath}/tmpBak">
            <include name="**\*.as?x" />
          </fileset>
        </copy>
      </do>
    </foreach>
    <exec program="${ilmergePath}" commandline="/out:${mergedAssemblyName} ${assemblyFiles}" workingdir="${ProjectPath}/bin"/>

Tags: , ,

2.0 Port Update 2: Mixed Progress

After spending most of the day yesterday writing specifications for version 1.2 of the Digipede Network, I spent the afternoon continuing to migrate our projects over to VS2005. This went a little slower than expected, as I fell into a trap regarding upgrading ASP.NET projects.

The Gotcha

ASP.NET 2.0 projects are organized somewhat differently from their predecessors. One major change is that the project file is gone. This makes sense considering there has been much effort to make the Web site synonymous with the project itself. This means that every web page in a folder is a part of the project. Upgrading the project is simple: locate and open the old project file (.csproj in our case). VS2005 takes care of the rest.

But what if you attempt to upgrade it directly from source control? This works as expected for non-ASP.NET projects: simply select the project folder from source control. The project and related files are checked out from source control, and the project file is upgraded. But what happens for ASP.NET?

If you open an old ASP.NET project directly from source control, VS2005 doesn’t even look at the old project file (presumably it determines it is a Web project by the existence of web.config). It assumes that the project is in the new format. You do get prompted to upgrade to ASP.NET 2.0, but you don’t end up in the Upgrade Wizard. As a result, you get an application that has not been reorganized for ASP.NET 2.0.

So, don’t make this mistake! Get your files first and then upgrade from her whole project file.

ASP.NET 2.0 Reorganization re:Source Control

Another related issue is actually a slight beef I have with the Upgrade Wizard (OK, with the decisions made regarding it).

After upgrading your ASP.NET 2.0 project, you will likely get a message that says your project has been disconnected from source control. This is due to the project being reorganized. For example, shared source code files will have been moved into the App_Code folder. The solution suggested by the Upgrade Wizard is to add your project back into source control. Yes, that is a solution.

But what about file history? I take great pains to retain file history in source control. I don’t need to go into the reasons why (as I think they are obvious). It is important enough that I have manually tweaked the source control projects to retain the file history.? This is a bit of a time sink, but again well worth it.

Why doesn’t the Upgrade Wizard offer to move these files in source control? VS2005 does support source control file move (even with a VSS 6 source control provider). It would have saved me some hassle if this was taking care of automatically.

Inconsistency with Source Control

I found an inconsistency in the way the upgrade process deals with deleted files. In at least one case, the user is prompted to automatically remove the deleted file from source control. In another case, it is left to the user to go through the upgrade report and determine which file should be removed from source control:

  • XSDs (and related files) representing DataSets are converted from the old format to the new VS2005 format. In this process, a new file gets added (the Designer.cs file) which replaces the old code-behind file. In this case, VS2005 asks the user if the deleted file should be removed from source control.
  • The upgrade removes.resx files that contain only header information. Unfortunately, VS2005 does not from the user to delete these files from source control.

Tags: , , ,