May 2003 - Posts

Versioning and Release vs Debug builds

We have a pretty large application > 200 projects which my main responsibility has been to build and deploy - the tools and processes to do so.

We have a number of versions "out of house" now and need to be able to support devs fixing these builds or at least verifying bugs.  The nightlybuild process supports this by creating a build number, a build directory and labeling in VSS for QA deploys.

We can always build old projects but we also need to have the builds deployed for testing.  The easiest way seems to be separate servers.  The app uses webforms webservices and deploys "smart client" winforms.

QA also wants to start getting Release builds while Dev wants debug builds.  For each nightlybuild I increase a build number and update all the AssemblyInfo.cs files to it.  That still means that we cannot tell the difference between a release dll and a debug one.

One thought was to embed that information in the AssemblyInfo.cs file as a comment while I am updating it for the new version.  Then, using winexplore you can see whether it is debug or release.

It also occured to me that it might be possible to determine debug vs release using reflection.  Somewhere in a blog, I wish I could remember - I should have commented the code after downloading, a way to do this using DebuggableAttributes.

A code snippet is: (This is ugly, I wish I knew how to copy and paste into here a better way)

System.Reflection.Assembly asm = System.Reflection.Assembly.LoadFrom(args[0]);

object[] atts = asm.GetCustomAttributes(typeof(DebuggableAttribute), true);

if (atts.Length == 0)

{

MessageBox.Show("DebuggableAttribute NOT present");

return;

}

DebuggableAttribute da = atts[0] as DebuggableAttribute;

if (da != null)

{

bool standardDebugBuild = da.IsJITOptimizerDisabled &&

da.IsJITTrackingEnabled;

MessageBox.Show(string.Format("standardDebugBuild = {0}", standardDebugBuild));

}

Of course I have to wonder what the differences are in performance between debug and release.  I have asked this before on the win_off_topic list and got no "for sure" answers. It will take some testing.

 

Posted by cloudycity | 1 comment(s)

.NET 1.1, Win2003, PC hardware woes

I haven't kept up on my promise to keep diggining into the .NET unknowns on a daily basis.  Lots of excuses but I really need to get over the next .net learning curve bumps.

I am getting pretty OK at C#, I have a fairly large work project and have expanded it into  a number of .net corners.  I have been poking at Don Box's book but not regularly enough.

At work we have just converted over to .net 1.1 and win 2003 for our servers.  An interesting exercise.  1.1 was pretty easy, win 2003 takes some "read the f... book" stuff.  Still discovering the differences between the different versions, especially the Web and Standard.  One of my deploy tools works on Standard and fails on Web in the UI portion.  The only thing that slowed me up in converting my tools was the changing of the deploy directories and IIS setup to make use of new IIS6 features whick seem pretty cools so far.  Application pools, etc. but especially the copying of metadata for WebSites and application pool to other servers.

One of my problems in delving more deeply into some of the corners of .net - security, remoting, web services (beyond simple vs.net created) ... is that these aren't really required for my work projects and I can't justify adding complications.  I would just as soon have these tools stable

Posted by cloudycity | 1 comment(s)
More Posts