Codebureau - Matt Simner

This is obviously what happens when you get really serious about technology like Mr Hanselman and want to work remotely...

There's a fairly major annoyance about VS2005 and the fact that when you create 'New Class' it effectively creates the class as private.  This article explains how to change it...

http://mark.michaelis.net/Blog/ChangingTheDefaultItemTemplatesInVisualStudio2005.aspx

I've been told and have read many times that it's not possible to run Microsoft CRM 3.0 under .NET 2.0.  Well, I guess 'not possible' could just mean 'not supported'.  All of our code base is now .NET 2.0 and I was loathed to maintain .NET 1.1 versions of our framework libraries jsut for a couple of calls out of CRM. 

I had previously found this article on extending CRM with ASP.NET 2.0 apps, but needed to create a Workflow component to call into our internal systems and found that this obviously didn't work because (all of) CRM runs under .NET 1.1.

A bit of 'give it a try' later and I can reveal that it is indeed possible to successfully run CRM 3.0 in a .NET 2.0 process, and also use .NET 2.0 assemblies with Workflow.  I'll leave it up to the reader to decide whether this is a good idea that they'd actually want to implement!  The process isn't too onerous so wouldn't take long to roll back if you encountered problems.

If you're still up for giving it a try then you'll need to alter the ASP.NET properties for the CRM Web Site and Service ...

Make sure you've set up separate app pools (see below), as one will run all your ASP.NET 1.1 apps, and the other will run the .NET 2.0 apps.  You can't run a mixture of runtimes within the same app pool.

Change the Microsoft CRM v3.0 site's root folder, AND the MSCRMServices virtual folder as below to use .NET 2.0 (and make sure they're configured to be in your .NET 2.0 app pool).

Now to ensure Workflow can use .NET 2.0 you'll need to add a .NET config file to force the Workflow Service to run in the .NET 2.0 runtime.

Stop the "Microsoft CRM Workflow Service", then Add a file as below in the CRM Workflow binary folder.

The contents of the file should be as follows:

<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
  </startup>
</configuration>

Restart the Workflow Service (and probably do another IISReset for good measure), and you should find everything comes up fine, and you'll be able to configure Workflow as per normal but now with .NET 2.0 assemblies.  I'm not too familiar with 'where' callouts run, but I'd presume that the same principles should apply and .NET 2 assemblies should work OK.

This procedure is obviously not supported by Microsoft so you use at your own risk, but I've had no problems so far....

What next - COBOLUnit?  Haven't tried this yet, but this could be a good tool for 'self-diagnostic' tests on Servers...

http://www.codeplex.com/psexpect/Wiki/View.aspx?title=User%20Guide&referringTitle=Home

Like many people I'd mistakenly thought that xxx.Parse was the only way to validate types like ints and DateTimes.  This kindof 'was' the case in .NET 1.1, but numeric data could be validated with Double.TryParse then converted to the correct type.

In .NET 2.0 you can happily use the TryParse method on pretty much all the types you'd want to validate - without the nasty overhead of catching an exception.  This post goes into a bit more detail, and links to a tool to benchmark the results for yourself.

I'll be on the lookout to convert whereever I find int.Parse, as it's pretty rare you 'actually' want an exception to be thrown...

This excellent post from Jake Lawlor's a great practical guide to applying agile processes in the real world. 

This isn't new thinking by any means, but when trying to coach others and improve your own processes you find surprisingly few practical reference points for applying agile processes into actual organisations.

Just found a useful post that helped in resolving why Custom Attributes weren't being copied from Leads to Contacts when 'Converting' a lead.  It's all in the mappings...

http://blogs.inetium.com/blogs/rtoenies/archive/2006/07/31/272.aspx

Just downloading a few .NET 3.0 bits and pieces from MS and happened across some 'you might like to download this' links.  Once of which was Windows PowerShell.  Haven't tried it yet, but will certainly give it a go in my next 'scripting' escapade.

Microsoft have obviously developed this quite a lot based on the amount of documentation I've not had chance to look at yet!

ReSharper's got plenty of functionality (more of which I find and use as time goes on), but I found this on Joe White's blog that is certainly a useful reference and taught me a couple of new things too..

I spotted an old post from Brad Abrams on breaking changes for .NET 1.1 apps recompiled with 2.0.  The links had moved but are still relevant...

http://msdn2.microsoft.com/en-au/netframework/Aa570326.aspx

My own observations from converting projects are a little higher level in that I'm also interested in what effort you're liable for when converting, and also things to watch out for if (like me) you're having to persist a 'shared' code base of 1.1 and 2.0 core libraries (temporarily) while you migrate all your client apps.

ASP.NET Projects.  This includes Web Service projects.  You'll find that you'll probably have to reconstruct these projects based on the content files and you'll also need to make a decision on the model you're going to use for debugging - i.e. whether to use the new debugging host (removing IIS from the debugging equation) and whether to use a dynamic or static port.  Steer clear of the 'Web Site' project too as this could leave you confused for hours wondering why you can't debug anything - look for the ASP.NET projects.  More info on the ASP.NET side can be found from Peter Laudati's post.  Microsoft also have an article covering conversion of ASP.NET projects

DataSets.  These have changed in that a 'designer' file is now the main source file (apart from the .xsd).  If you're sharing DataSets across 1.1 and 2.0 projects just share the .xsd file otherwise you'll be asking for trouble as the other generated files are incompatible.  Any structural changes to a DataSet in one project (say .NET 1.1) will not be reflected in the corresponding 2.0 project.  You'll need to check out the XSD in both places (assuming you're using VSS) and build both in order to avoid breaking one of the projects.

Windows Forms.  I've had a recent experience where the InitializeComponent() method in a form (edited with VS 2005) places calls that aren't compatible with .NET 1.1.  The code compiles (as below) but 'exception thrown by target of an invocation' gets thrown on the following line...

((System.ComponentModel.ISupportInitialize)(this.validatingProgress)).BeginInit();

This is because the control (a PictureBox in this case) doesn't implement ISupportInitialize in .NET 1.1 but does in 2.0.  The equivalent in 1.1 is SuspendLayout()

This would just be one example of something that's syntactically correct, but could fail at runtime.