My Graduation Cake
My wife used the C# Wallpaper from IrritatedVowel.com on the top of my Graduation cake...the results are pretty snazzy!  Everyone was quite impressed with code on a cake, although lots of not-so-funny-people insisted there were some syntax errors...:)
Updated Link to this post 1:27:49 PM  #    comment []  trackback []

Schweet: Free .NET Hosting for Developers

Here's a useful and exciting thing to discover on my return from TechEd:  EasyStreeet is offering Free .NET Hosting for Developers.   It's Six Months Free with the .NET Framework 1.1, with ASP.NET, all the BCL (of course), and support for Web Services.

I've been looking around at inexpensive but powerful ASP.NET Hosting to get some of my other small projects off the ground (in addition to www.diabeticbooks.com and www.pioneercourthousesquare.com among others) and this looks like a deal that's too sweet to pass up...might be a nice way to start testing out some blogging and RSS aggregation thoughts, as well as some No-Touch-Deploy WinForms.

All you have to do is email them to get setup:

To submit your request: email your name, company name, email and phone number to NETPlayground@easystreet.com.

Updated Link to this post 12:54:49 PM  #    comment []  trackback []

WSDL Cleanliness is next to Godliness (actually Cleavage is next to Cleanliness and Goggles is next to Godliness...)

So let me start my own little possee here and cry: Say No to inline schema definitions in WSDL! Import is your friend.... [Commonality]

I'm with Tomas on this one. Schemas should be written as standalone documents and then be imported into the WSDL document. Not only is this easier to manage for the developer writing the schema and WSDL, but it's also easier for those who have to grok the two. Besides, the service you're writing the WSDL for probably isn't the only thing that's going to need access to the types you define in the schemas. [Drew Marsh]

Totally...not only WSDL First! and <xs:import> but (maybe this is obvious) I'm getting in the habit of putting the Domain Object-y definitions that we use elsewhere and the SOAP-y GetDomainObjectResult/Response definitions into separate XSDs.  I preached this at TechEd last week and spoke briefly to Tomas about it although we didn't have enough time to really dig in.

 <wsdl:types>
    <xs:schema>
   <xs:import namespace="http://banking.corillian.com/Account.xsd" schemaLocation="Account.xsd"/>
   <xs:import namespace="http://banking.corillian.com/Banking/GetAccounts" schemaLocation="GetAccounts.xsd"/>
  </xs:schema>
 </wsdl:types>

In this small example, the Account.xsd schema contains all sorts of Account-specific definitions that we may pass around internally to our app (on Queues, to functions, as objects, without SOAP) and GetAccounts.xsd contains definitions for GetAccountsResult and GetAccountsResponse and other useful "container" definitions in a separate namespace.

Updated Link to this post 10:38:42 AM  #    comment []  trackback []

"Gotchas" around Primary Interop Assemblies and the GAC

A couple of things to be aware about when working with PIAs, particularly when deploying them.  PIAs provide a unique type identity for COM Components.  They provide a single place for your .NET app to interop with existing COM objects.  They get marked with the PrimaryInteropAssembly attribute...if there's any question about an assembly, you can ILDASM it and see the PrimaryInteropAssembly attribute in the Manifest. 

You can create a "vanilla" PIA with TLBIMP.exe like this (note the /primary key):

TlbImp MyCom.tlb /primary /keyfile:MyKey.snk /out:MyPIALib.dll

If you want to create a custom PIA, perhaps to marshal types a specific way you'll apply the attributes from source:

[assembly:Guid("xxxxxxx-xxxx-xxx-xx-xxxx-xxxx"]
[assembly:PrimaryInteropAssembly(3, 1)] //Version 3.1

Of course the COM Object that you're referring to has to be registered, but the PIA has to be as well.  You'll need to call RegASM.exe to create a key in the registry under HKEY_CLASSES_ROOTTypeLib{yourclassid}PrimaryInteropAssemblyName.  The value of this key should be the fully qualified Assembly name like: MYDLL, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.  Some folks call RegASM, others ship a .REG file or create this key during the installation procedure.

To recap:

• Register COM Object (if not already)
• Create InteropAssembly with TLBIMP.EXE and /primary (make sure it's strongly named)
• RegASM the resulting InteropAssembly
• Put the PIA in the GAC

Note also that when referencing your PIAs in Visual Studio.NET via "Add Reference..." you won't find your PIA in the .NET Tab as some may think.  Just select the original COM TLB/DLL reference from the COM Tab and Visual Studio will silently search for and use the PIA.  You can confirm this by looking at the added reference in the Properties Toolbox and confirming that it's strongly named.

Also check out Sam Gentile's article about Programmating Determining if a PIA in in the GAC and Mattias' page on the Fusion APIs.

Updated Link to this post 10:18:55 AM  #    comment []  trackback []