January 2004 - Posts
Hmm. It would seem that Visual Studio .NET 2003 doesn't like running post-build events for projects loaded from a UNC path. How terribly unfortunate. The error it gives is:
Performing Post-Build Event...
'\\unc\path\here'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
'PostBuildEvent.bat' is not recognized as an internal or external command,
operable program or batch file.
Eek. Looks like Microsoft is stopping support of the good old SOAP Toolkit. Not terribly suprising, but I think they could have given us a little more time. July 1, 2004? We use the SOAP Toolkit in our (still mostly) COM-based system, and 6 months is an awfully short timeframe in which to rip out that code and integrate the .NET Framework. Guess we'll be working without a net for a bit.
Update: Looks like Microsoft is giving us a brief reprieve, and extending support for a while. Standard support now ends April 2005, extended support ends April 2007.
Thanks to Dave Bettin et al for pointing me at the “Indigo: Coming Attractions” PDC presentation. That definitely cleared up some of my concerns about the Indigo programming model. If I understood it correctly, ASMX's
HelloService service = new HelloService();
Console.WriteLine(service.Greeting("ASMX client"));
now becomes:
ServicePort port = new ServicePort();
IHelloService service = port.CreateChannel<IHelloService>(“http://www.helloservice.com/...“);
Console.WriteLine(service.Greeting("Indigo client"));
which is definitely a step in the right direction. My inner Mort still wonders if the ServicePort/Channel stuff always needs to be exposed to the developer. Would a Service class that implements the interface and wraps up the ServicePort goo really be so bad? I'm sure many SOA purists will say yes, and that ASMX's model is all badness, but I'm not totally convinced.
Indigo does look pretty amazing though. Unbelievably extensible (which is fantastic as long as the complexity doesn't bleed through when it shouldn't). Extremely cool stuff.
I recently read Yasser Shohoud's article about creating Indigo applications using the PDC Whidbey bits, and it has me a little worried. I missed the PDC, and this article was really my first look at the details of writing code against Indigo.
In particular, I'm worried about the Service Framework (SFx)-level client APIs. One of the beauties of the ASMX/Web Reference model in .NET 1.x was its simplicity - especially for clients. At first look, the SFx programming model isn't nearly as Mort-friendly as the Web Reference model. For example, we've gone from this:
HelloService service = new HelloService();
Console.WriteLine(service.Greeting("Indigo client"));
to this (using Yasser's example):
ServiceEnvironment se = ServiceEnvironment.Load();
ServiceManager sm =
se[typeof(ServiceManager)] as ServiceManager;
se.Open();
Uri uri = new Uri("soap.tcp://localhost:46001/HelloService/");
IHelloChannel channel = (IHelloChannel)sm.CreateChannel(
typeof(IHelloChannel), uri);
Console.WriteLine(channel.Greeting("Indigo client"));
Console.WriteLine("Press enter to exit");
Console.ReadLine();
se.Close();
This is not what I would consider a very Mort-ly API. In fact, I'm worried that many of my company's customers would run screaming if they saw that bit of sample code. These are not dumb people - they're just trying to build applications that solve business problems, not necessarily build infinitely scalable multi-stage web service pipelines. Many of these people are coming from the VB6 environment, which was (and probably still is) the primary development environment for internal corporate Windows applications for many years. Heck, a lot of these people are still trying to get their heads around inheritance, and interface based programming was hidden well enough by VB6 that even though they could do it, they mostly didn't.
I agree that ASMX hides too much both the server and client. There are times that I very much miss the fact that I don't have access to the underlying XML. But looking at that sample makes me think that maybe Indigo has gone too far the other way. If it's too complex, the average corporate developer won't embrace it. Imaging how COM would have fared if VB6 hadn't spared the average corporate developer from the complexity of IDL, proxy/stubs, event sinks, etc.
As I said, my expose to Indigo is minimal thus far, so perhaps I just don't understand the model well enough (I'm still fuzzy on the scope of ServiceEnvironments, for example). Or perhaps VS.NEXT will hide some of that complexity in the next incarnation of the Web Reference. But right now I'm left wishing for a little more country, a little less rock and roll.
Recently an article went up on MSDN about cryptography with the .NET framework. I've seen many articles like this. Know what? Almost every single one does what this article does - creates helper functions that take a chunk of plain text and return a chunk encrypted text. I must have seen this same chunk of code a dozen different times.
Perhaps this is an indication that the framework needs a couple of high-level encrypt/decrypt-a-string methods. The stuff that's in the framework is great, but apparently it's calling out for a couple of simple additions.
Although then article writers would have to come up with a new boilerplate sample, and it would be a shame to make their live's more difficult.
Will there ever come a day when Windows Explorer, when it encounters an error during a file copy (due to a sharing violation, for example), actually gives you the option of skipping the problem file and continuing on with the copy? As opposed to the current behavior, where it just bombs out and stops copying.
Dare to dream.
Fabrice points to an MS Research tool called ILMerge that can be used to merge multiple assemblies into one. This reminded me of some tinkering that I did a while back with creating single-file executables. I didn't have an explicit need for this, really, but from an aesthetic perspective there's something nice about a program that consists of just a single file. Plus, it's the ultimate in xcopy deployment.
Anyway, I took a different approach from the MSR guys - I embedded the referenced assemblies as manifest resources in the executable and then hooked into the ResolveAssembly event of the AppDomain. It seemed to work pretty well. If anyone's interested, I posted a sample of my tinkering here.
During a recent chat session on debugging with Visual C#, the following questions and answers came up:
Q: Will generated classes from tools such as xsd.exe and wsdl.exe (and the equivalent in IDE) produce partial classes?
A: We are still identifying code gen areas where it makes sense to create partial classes. I'll pass your suggestion on.
Q: Wouldnt it make sense to always gen partial classes? I cant think of any reason why you would NOT want this.
A: Agreed. Unfortunately, although the compiler supports partial classes, the work in the IDE and debugger to support them is still ongoing. For instance, how do we present partial class source files in Solution Explorer? Into which partial class source file do we insert genned code? ETc, etc. (BTW, this is not to say we don't have answers, but like most things, the answers have to be refined.)
I'll add a big +1 to the request for partial class support in the .NET codegen tools. I'd love to be able to add some smarts to web service proxy classes without having to worry about refresh wipe-outs.
More Posts