I attended a seminar on .Net hosted by Iridium today. Met some interesting people, including a guy from Philips Belgium, a Micro$oftie developer, and another .Net code junkie (some useful links there).
The seminar covered Classic ASP-ASP.NET Interop; a bit on COM Interop; Windows DNA plus .Net for 3-tier development; Windows XP SP2; and VS.Net 2005/.Net 2.0.
Early-adopters tend to stumble upon problems with new technology (sounds familiar!?!). Co-existence between Classic ASP and ASP.NET is possible, but a bit of a hack. In particular, the sharing of Session information is difficult; easier if data types in the Session are simple, and can be stored in a SQL DB, but otherwise tricky (storing big objects in the Session is bad practice anyhow, but that’s another story). Direct interaction between Classic ASP and ASP.NET is possible by using COM objects – either wrapping a .Net class as a COM object, or by using a RCW on a VB-style COM object. Btw, keeping the 3-tier model alive in ASP.NET perhaps needs some discipline, with “visual” components such as DataGrid so easily accessible from the Presentation layer.
.Net can expose functionaloty as COM objects with ease. To wrap a C# class as a COM object, give it Guid and InterfaceType attributes:
using System.Runtime.InteropServices;
...
[Guid("F09684D5-D3EF-4838-8BBC-726EF122566F),
InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface MyComExposedNetInterface
{
...
}
Then declare a class which will act as the CoClass:
[Guid("0D53A3E8-E51A-49C7-944E-E72A2064F938"),
ClassInterface(ClassInterfaceType.None)]
public class MyNetComClass : MyComExposedNetInterface
{
...
}
The ClassInterfaceType.None directive restricts the methods exposed via COM to those defined in that particular .Net class (rather than those in base classes etc.). Compile and go! .Net registers the COM object internally, so that clients callinng into the COM object actually call into the .Net runtime, which manages the location and versioning of the component – nice.
In a Three-Tier model (Data, Business, Presentation), the Business layer should be stateless. This means that the Presentation layer should pass in all the parameters it needs in order to retrieve the information it requires. The Data layer in .Net is simplified compared to DNA because ADO.NET handles much of the Database connectivity issues for the programmer.
Windows Firewall, NetSh.exe,
blah, blah, Popup-blocking in IE, blah. More interesting was news that the entire of Windows XP SP2 (i.e. a good chunk of the Windows code base) has been recompiled with the /gs switch.
Some cunningness with “magic” numbers placed on the stack between function calls means that buffer overflows can be trapped more reliably. SP2 may break apps due to DLL versioning, but this can be fixed by using Side-by-Side deployment and application .manifest files to direct the app (well, the application loader) to the correct DLL version. Managing the XP Firewall could be a pain for software developers. I asked about MSXML versioning – it’s a real pain to be stuck with an ancient parser.
Lots of nice goodies in VS.Net 2005 [side-note: some of this testing functionality already exists in Application Center Test], though only if you pay Big Bucks. The Team System will have integration IDE, Bug/Issue Tracking, Bug Reporting, Testing, Deployment, etc. Bugs
will be automatically added to a database, complete with line-number and filename where the error occurred. Generics will enable generation of specific classes on-the-fly, rather that at compile-time. ASP.NET 2.0 will have built-in Controls for Authentication, Login, User Profile management, to name a few, along with ability to add new .aspx pages after deployment.
Matthew Skelton 