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

VS 2005 Countdown

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

2.0 Port Update 1

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

Journey to .NET 2.0

After some discussion about the timing of a move to .NET 2.0/VS2005, we have decided to take the plunge and natively build for .NET 2.0 for (a currently planned) release in November.  The main reason we have delayed in this decision is that we need to continue supporting current and prospective customers who, for various reasons, are not ready to move from .NET 1.1.

 

There are a couple of things about our product that make this a bit more complicated than simply upgrading all of our VS2003 projects.:

 

1.      We offer a .NET API to our product.  Since we are committed to supporting .NET 1.1, we will have to continue maintaining a 1.1 version of the API’s main assembly.

2.      The Digipede Network can instantiate distributed objects, serialize them, and return them to the caller of the API.  If the caller is using the .NET 1.1 CLR then the serializing assembly cannot be running in a newer CLR; otherwise, deserialization errors will occur. To solve this problem we need to select the proper CLR based on characteristics of the caller (or, more practically, on configurable requirements).

 

These details are worked out (and basically functional), so what is left is integrating the new tools into development, build, and test.  We have already tested it all against .NET 2.0, so there is little concern there.  The CLR team has done a great job on compatibility.

 

Integrating the tools is (mostly) straightforward, but includes nant, NDoc, ResHacker, FxCop, Dotfuscator, NUnit, NCover, XHEO, Infragistics, NDepend, and Resharper. 

 

Some of these are critical for our commercial release and some can be dealt with later.

 

I’ll continue to post about this port with any gotchas I come up with.

Tags: , , ,

XML Intellisense in VS2005

When I was at , I was talking to Faisal Mohamood about performing distributed builds on the Digipede Network.  I had a question about Intellisense in VS2005 and he said something like “Really?  That should just work”.

Finally I have gotten to sit down and spend a few focused minutes on this Intellisense issue.  Our XSD works great in VS2003, but not in VS2005.  Lots of warnings that look like this:

Type ‘x’ is not declared in namespace ‘y’.

I made the assumption that the VS2003 schema was actually valid; but it turns out that it wasn’t.  Strangely enough, it appears that VS2003 is much more forgiving about errors in XSD than VS2005 is.  I’m happy to say that the XML validation features of VS2005 told me what was wrong with the schema and it was easy to fix.

Note: our original schema had been created using xsd.exe from a class library.   I had to tweak some things in it by hand, but basically VS2003 accepted it as it was generated.  Oddly, it had several problems in it.  The most major one (and the cause of the problem above) is that there were many top-level element nodes that should have been complexType nodes.  It seemed kind of arbitrary whether types were defined or not.  So, don’t trust xsd.exe for creating valid XSD.

Tags: ,

« Previous entries