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

2.0 Port Update 3: On to Release Engineering

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: , , , ,

    Trackback

No comments yet

Sorry, the comment form is closed at this time.