.NET

Digipede Webinar, November 1

Robert W. Anderson — Fri, 28 Oct 2005 15:55:00 GMT

Dan Ciruli and Nathan Trueblood will be running a webinar on the DN, showing how to speed up applications. They do a great job of giving an overview of its power and functionality. The focus of this webinar will be financial applications.

Go here for details on what will be covered and to sign up. It is scheduled for 10AM Pacific and will be about 30 minutes.

2.0 Port Update: Finished (for now)

Robert W. Anderson — Fri, 28 Oct 2005 10:01:00 GMT

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.

Renaming ASP.NET 2.0 Assemblies Redux

Robert W. Anderson — Thu, 27 Oct 2005 14:48:00 GMT

I have posted a bit on merging ASP.NET 2.0 (without aspnet_merge) and also on renaming ASP.NET 2.0 auto-named assemblies. My first solution on renaming was incomplete in that it would only work when there were no dependencies between the renamed assemblies.
This solution is correct and produces assemblies that properly get through Dotfuscator 3.0 / and actually run! All of the code below are either nant targets or nant tasks. These should be generally applicable (with the right properties assigned).

Disassemble the assemblies with ildasm.
Get the generated assembly name for a particular folder from a representative file (either an aspx or ascx).
Replace the assembly name for all files (pages, controls, and the il) with a fixed name (e.g., “App_Web_Root”).
Reassemble and rename the assembly's DLL to the fixed name (using ilasm).

These targets assume the following properties are set:

ProjectPath

the path to your build project directory

ildasm

the full path to the ildasm executable

ilasm

the full path to the ilasm executable

The first part is disassembly (the most straight-forward part):

  <!-- disassembles all App_Web assemblies to il -->
  <target name="disassembleAspNet20Assemblies" >
    <foreach item="File" property="assembly">
      <in>
        <items basedir="${ProjectPath}\bin">
          <include name="App_Web*.dll" />
        </items>
      </in>
      <do>
        <exec program="${ildasm}" workingdir="${ProjectPath}" commandline="/out=${assembly}.il /nobar /raweh /utf8 /quoteallnames /linenumbers ${assembly}" />
      </do>
    </foreach>
  </target>

The second part is to change the files to point to the new name:

  <!-- Renames a generated-assembly for ASP.NET 2.0 -->
  <!-- 'page' property is a representative page or control in the folder -->
  <!-- 'fixedAssemblyName' property is the new desired name of the assembly -->
  <target name="renameAspNet20Assembly">
    <loadfile property="loadedPage" file="${ProjectPath}\${page}" />
    <!-- get the assembly name from the representative page -->
    <regex pattern="(?'assembly'App_Web.+\s*)\042" input="${loadedPage}" />
    <!-- store the assembly name to fixed name mapping -->
    <property name="${assembly}" value="${fixedAssemblyName}"/>
    <!-- copy all of the pages (and il), replacing this assembly name with the fixed name. -->
    <copy todir="${ProjectPath}/tmpBak" overwrite="true">
      <fileset basedir="${ProjectPath}">
        <include name="**\*.as?x" />
        <include name="**\*.dll.il" />
        <exclude name="tmpBak\**" />
      </fileset>
      <filterchain>
        <replacestring from="${assembly}" to="${fixedAssemblyName}" />
      </filterchain>
    </copy>
    <!-- copy them all back -->
    <copy todir="${ProjectPath}" overwrite="true">
      <fileset basedir="${ProjectPath}/tmpBak">
        <include name="**\*.as?x" />
        <include name="**\*.dll.il" />
      </fileset>
    </copy>
  </target>

Finally, the assemblies must be reassembled:

  <!--  Reassembles all the App_Web*il into a new fixedAssembly.  -->
  <!-- This requires that the il's assembly name exists as a property that maps to the new fixedAssembly name.-->
  <target name="reassembleAspNet20Assemblies" >
    <foreach item="File" property="assembly">
      <in>
        <items basedir="${ProjectPath}\bin">
          <include name="App_Web*.dll.il" />
        </items>
      </in>
      <do>
        <!-- get the old DLL name -->
        <property name="dllName" value="${path::get-file-name-without-extension(assembly)}"/>
        <!-- get the old assembly name -->
        <property name="assemblyOnly" value="${path::get-file-name-without-extension(dllName)}"/>
        <!-- get the new, fixed assembly name -->
        <property name="fixedAssemblyName" value="${property::get-value(assemblyOnly)}"/>
        <!-- reassemble -->
        <exec program="${ilasm}" workingdir="${ProjectPath}" 
                  commandline="/out=${ProjectPath}\bin\${fixedAssemblyName}.dll /dll /res=${ProjectPath}\bin\${dllName}.res ${assembly}" /> 
        </do>
    </foreach>
  </target>

Then, for each folder, I call the target like so:

    <!--Dissasemble the assemblies-->
    <call target="disassembleAspNet20Assemblies"/>
    <!-- use Administration.aspx as a proxy for the site's root directory -->
    <property name="page" value="Administration.aspx" />
    <property name="fixedAssemblyName" value="App_Web.ControlRoot" />
    <call target="renameAspNet20Assembly" />
    <!-- use Login.aspx as a proxy for the site's Secure directory -->
    <property name="page" value="Secure\Login.aspx" />
    <property name="fixedAssemblyName" value="App_Web.Secure" />
    <call target="renameAspNet20Assembly" />
    <!-- use Headers.ascx as a proxy for the site's Control directory -->
    <property name="page" value="Controls\Header.ascx" />
    <property name="fixedAssemblyName" value="App_Web.Controls" />
    <call target="renameAspNet20Assembly" />
    <!--reassemble the assemblies-->
    <call target="reassembleAspNet20Assemblies"/>

VS2005 RTM Available on MSDN Subscriber Downloads

Robert W. Anderson — Thu, 27 Oct 2005 13:02:00 GMT

After much speculation by many (on whether or not it would be before the 7th), it is available.

This is good news for those of us exhibiting at the VS launch -- we will be able to show off the Digipede Network from the final Visual Studio.

Renaming ASP.NET Assemblies (Correction)

Robert W. Anderson — Mon, 24 Oct 2005 16:45:00 GMT

I found an error in my ASP.NET 2.0 assembly-renaming script (see Renaming ASP.NET Assemblies).

The regular expression isn't matching all assembly names that might be generated by the compiler. This expression does the trick:

(?'assembly'App_Web.+\s*)\042

Simply replacing the pattern in the nant regex task solves the problem.

Dan is off to Code Camp

Robert W. Anderson — Fri, 21 Oct 2005 21:54:00 GMT

Dan is off to Code Camp in Seattle this weekend. He'll be talking on Sunday @ 3 about grid-object oriented programming (what he calls GOOP). He'll be talking about that and showing the Digipede Network at the same time.

If you are going to be there drop by and see him.

VS2005 Ships!

Robert W. Anderson — Fri, 21 Oct 2005 16:43:00 GMT

Where, I don't know. It isn't yet on MSDN. Robert Scoble said that it (and SQL Server 2005 + BizTalk 2006) are done in Three VPs on Channel 9. Tonight is the shipping party.

Congratulations to all of the teams at Microsoft that have been working on this!

Renaming ASP.NET Assemblies

Robert W. Anderson — Fri, 21 Oct 2005 11:12:00 GMT

I have removed this solution in favor of a new, more robust, solution. You can find it on my new blog, here: Renaming ASP.NET 2.0 Assemblies Redux.

Merging ASP.NET 2.0 without aspnet_merge

Robert W. Anderson — Thu, 20 Oct 2005 17:54:00 GMT

This post and more can be found on my active blog, here.

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.

2.0 Port Update 3: On to Release Engineering

Robert W. Anderson — Thu, 20 Oct 2005 13:16:00 GMT

I probably have not been clear in my previous posts about the overall methodology I'm following in our port to VS2005. I have split my porting process into several different steps to isolate the effort into manageable slices. These include:

Porting the projects into VS2005 for ongoing development. While doing this, I have insured that everything still builds with VS2003 while my team makes the transition to the new IDE. I am avoiding the temptation to fix the thousands of warnings related to deprecated functions. That we will start fixing these as soon as the rest of the team is using VS2005.
Porting our release engineering process. I view this as the next most critical item as I want to have our testers began working with the new versions as soon as possible. Note that I'm leaving installs and install issues out of this altogether as this is not managed inside of my group.
Continuous integration with CCNET.
Digipede Network product features regarding mixed .NET 1.1 / .NET 2.0 environment and continued support for VS2003.
Evaluation of WSE3 to determine its viability relating to our release schedule.
(future) Evaluate performance improvements that can be achieved with .NET 2.0.
(future) Evaluate Team System (regarding unit testing and source control) and its applicability in our environment.

Wrapping up the Development portion

In addition to issues I brought up in my previous post (2.0 Port Update: Mixed Progress), I have come across a few more:

With the loss of the ASP.NET project file, many of the build properties are stored in the solution file. I think this is unfortunate. The ability to mix and match projects across different solutions gives the developer more flexibility (and I'm not a proponent of managing solution files in source control for this reason); however, this no longer really works with ASP.NET projects. If we continue to keep solution files out of source control then critical build information won't be versioned. This is not a huge problem, but I would rather not have to deal with this work-process issue while porting.
A slight annoyance: the ASP.NET 2.0 Project Properties dialog includes text boxes for paths to files (e.g., an SNK file). The UI for this translates the path into an absolute one. This is misleading, because the paths are actually stored as relative. It would be much more clear if the UI did no such translation.

On to Release builds

The release engineering process has gone fairly smoothly. I have been able to remove the hanging reference problem that is a bug in Dotfuscator (I blogged on that in my old blog here).

I have come across a somewhat major problem regarding the new ASP.NET 2.0 compilation model (K. Scott Allen has a good article here on this subject). I like the idea that multiple assemblies are now supported by the compiler; however, the way that the assemblies are named presents a problem for anyone who has automated the obfuscation (and possibly the building of installs). My biggest issue right now is getting the three Web site projects that encompass our solution into a state where I can reliably send them through our obfuscator. I will definitely blog on the solution I come up with.