rwandering.net
The blogged wandering of Robert W. Anderson
October 27, 2005 at 9:48 am · Filed under .NET
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"/>
Tags: .NET, vs2005
October 27, 2005 at 8:02 am · Filed under .NET
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.
Tags: .NET, grid, vs2005
October 21, 2005 at 4:54 pm · Filed under .NET, Grid Computing
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.
Tags: .NET, grid
October 21, 2005 at 11:43 am · Filed under .NET
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!
Tags: .NET, vs2005
October 20, 2005 at 8:16 am · Filed under .NET
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 previously 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.
Tags: .NET, ccnet, grid, vs2005, wse3
October 18, 2005 at 4:11 am · Filed under .NET
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: .NET, asp.net, grid, vs2005
October 17, 2005 at 3:58 am · Filed under .NET, Grid Computing
Our main push right now (aside from getting our Professional version out the door) is to finalize the specs for the next release of the Digipede Network: version 1.2.
There will be a few API improvements, many performance enhancements, native support for .NET 2.0, and more.
You might ask, what happened to version 1.1? Version 1.0 of the Digipede Networkis built on .NET 1.1. The next version will be built natively on .NET 2.0. Naturally, this version would have been version 1.1, but we felt this might confuse people. As the change from .NET 1.1 is a significant one to our customers, we felt that it might be easier just to skip 1.1.
Less confusing? I hope. Still confusing? Maybe. Misleading? I hope not.
I have always been very strict about proper use of version numbers and skipping a minor version could be perceived at a marketing ploy. That isn’t why we’re doing it, although I hope that our decision is viewed as slightly whimsical, if anything.
BTW: I was really hoping that the Visual Studio RTM would have been out last week. I need to get my development team using all of the new tools and would just as soon avoid an unnecessary tool install/upgrade cycle.
Tags: .NET, Digipede, grid
October 12, 2005 at 1:33 pm · Filed under .NET
Update: I think that Channel 9 is jumping the gun. I hear now that the RTM date is as of yet unknown.
2 more days to the RTM:
Channel 9 says the RTM will be available on MSDN Subscriber Downloads this Friday (October 14th).
And 26 more days to the launch:
We’ll be at the November 7th launch in San Francisco to show off our product with VS2005 and .NET 2.0!
This product launch has been eagerly awaiting by a very large group of people. We’re excited too. Drop by our booth at the SF launch and see us.
Tags: .NET, vs2005
October 12, 2005 at 8:16 am · Filed under .NET
I have completed my first litmus test for my planned approach for our .NET 2.0 port: that it is possible for a .NET 1.1 WSE 2.0 Web services client to interact with a ASP.NET 2.0 WSE 2.0 Web service. I am happy to report that this has worked with no trouble; however, there is a gotcha here for those intending to support VS2003’s “Add Web Reference” feature:
By default, ASP.NET 2.0 generates WSDL based on the SOAP 1.2 specification. VS2003 can only interpret the WSDL based on the SOAP 1.1 specification. I say “by default” because I assume this can be overridden; however, I may be wrong.
In terms of my overall progress, I have converted libraries, WSE clients and services, ASP.NET projects, ADO.NET clients, and Windows Services. There have been no real stumbling blocks, though I expect that the greater work will be integrating all of these new tools into our release processes.
One issue is that ASP.NET 2.0 assemblies are all compiled into an App_Code.dll. Anywhere that static references to ASP.NET assemblies exist (e.g., in the web.config file) need to be changed. This was the case for us in two sections: custom configSections and a WSE securityTokenManager. In both cases, I simply needed to change the 2nd argument in the standard full assembly name from the old simple assembly name (e.g., MyWebServices) to App_Code.
The other issue was that I had to #if out references to the PreEmptive.Dotfuscator.ObfuscationAttributes namespace as these attributes are built-in to .NET 2.0.
Other than that, everything is AOK.
BTW: I’m sticking with VSS 6 and not getting into Team System for now. I consider this a completely separate porting issue that I’ll get into later this year.
Tags: .NET, Digipede, vs2005
October 10, 2005 at 10:52 am · Filed under Grid Computing
Dan’s post (Grids? Clusters? Distributed Computing?) explains why we refer to the Digipede Network as “Grid Computing for Windows“.
Several speakers at the recent Microsoft eScience Workshop defined Grid as well and many others steered away from the term altogether. As Ian Foster and Carl Kesselman are generally credited with the definition of this term (from his book), there are many people who think of Grid as being exactly Globus. To these people, Grid means large, complex, multi-organizational, cross-platform (mostly Unix and its pretenders) computing systems that integrate sensors and visualization with distributed computing power.
As we are trying to bring simplification to this kind of computing, I wanted to steer away from calling our product a “Grid“. I truly thought it would be more confusing if we did so; however, I was wrong.
We found again and again that when we described our product we often ended with “you know, like a computing grid“. That was when people began to get it.
So, we decided to go directly to the punchline.
Of course, we have also had a few people ask us: your whole company is based on a grid (i.e., tabular UI) control? 😉
Tags: .NET, Digipede, grid
« Previous entries ·
Next entries »
About me
Main feed
Email subscriptions