May 2003 - Posts
One of the promises of the .NET Framework was that programming language would not matter. Maybe that is putting it too strongly. Programming language would of course matter (there are always some things easier in one language than another) but mixing languages should be transparent. In practice, it seems not to be.
For one thing, if you are using Visual Studio .NET, you are certainly encouraged to use a single language. For sure, you can have a solution with multiple projects, each in its own language, but how many of us do that?
In practice, I use C# for virtually all my work, unless the client for one reason or another insists upon using VB.NET or J#. I have a major client, and I had one class that was done for demonstration purposes (using VB.NET, the perferred language of the group I was demonstrating to). When in a later project for the same client, I had use for that class, it was a bit of a pain having to drop to the command line to compile the VB.NET class into an assembly that could be used by my C# application.
So, if anyone out there does make extensive use of multiple languages in a .NET application, what do you use? Do you use something like NANT? The command line? {shudder}Batch files?
Have you installed and started using Visual Studio .NET 2003? If not, if you have a Pocket PC you should run, not walk, to install VS.NET 2003.
VS.NET 2003 has, among many incremental improvements, a breakthrough: The ability to create and more importantly, debug, .NET Compact Framework applications. While it was certainly possible to create Pocket PC applications prior to VS.NET 2003, I do not know many people who have. I think there will be many people who will do so in the future. What is so great about developing with the .NET Compact Framework?
- The .NET Compact Framework is a reasonable subset of the full .NET Framework, making it possible to, with some care, create classes that can work on your desktop and your pocket PC.
- The VS.NET debugging environment is wonderful to work with. Even if you do not have a pocket PC, you can debug applications on the emulator.
- The .NET Compact Framework has a SQL CE data provider that works much like the SqlClient classes on the PC. It is not a perfect match, but it certainly can help limit the learning curve.
So, what's not to like?
- SQL CE does not allow use of Stored Procedures or Views. This makes it a little more difficult for me to reuse certain logic that I would normally place in a stored procedure.
- There are pretty severe limits to the power of the UI components. Want to change the color of the background on a drop down list? Not supported by the framework. Want an incremental search on a drop down list? Same thing.
- Certain operations (notably binding data) that are instantaneous on your PC will be lots slower on the Pocket PC.
The good news for me is that these lapses in what is possible and what the .NET Compact Framework provides means that there is room for an independent developer to cobble together class libraries to support what will be a growing number of .NET Compact Framework Developers.
What do you think?
Turns out that a couple of years ago, I actually created a Web Site to allow my sister-in-law and myself to post the ongoing story of my Neice's eventually fatal illness. That site was created with the first beta of ASP.NET, and is still available here.
Of course, I did not call it a Blog, and it was a while after I saw Blogs appearing that I even realized that I had created one. It was one of the neatest uses of technology I had seen at the time, since it allowed Ali and her Mom to let people know what was going on with her without needing to call them all the time.
More Posts