Ponder this....

2005-10-28T15:53:00.000-07:00

test blog

.Net will be one of Microsoft's biggest mistakes.....

2005-01-23T06:14:00.000-08:00

I think this sums it up best......

"Now Microsoft has so many developers cranking away that it's not enough to reinvent the entire Windows API: they have to reinvent it twice. At last year's PDC they preannounced the next major version of their operating system, codenamed Longhorn, which will contain, among other things, a completely new user interface API, codenamed Avalon, rebuilt from the ground up to take advantage of modern computers' fast display adapters and realtime 3D rendering. And if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon. Which explains why WinForms is completely stillborn. Hope you haven't invested too much in it. Jon Udell found a slide from Microsoft labelled "How Do I Pick Between Windows Forms and Avalon?" and asks, "Why do I have to pick between Windows Forms and Avalon?" A good question, and one to which he finds no great answer."

Joel Spolsky - http://www.joelonsoftware.com/articles/APIWar.html

.Net hasn't given us a straight answer to anything yet. .Net 1.1 is not backwards compatible with .Net 1.0. .Net 2.0 will not be backwards compatible with either of its siblings either.

.Net can't use all of the COM components that you spent a fortune amassing and is limiting the reach of valid technologies like ActiveX in the browser by no longer supporting the creation of activeX controls.

And, all of that scratching and clawing that you have done learning Winforms and Webforms? Hell, we'll just throw that out like we did Visual Basic 6 in favor of Avalon and WinFX.

Don't be concerned that Avalon and WinFX will ONLY run on Longhorn - everybody will upgrade as soon as it comes out. Right? I mean, everybody is on XP and 2003......aren't they? So, what else could you possibly need?

What's needed is a big fat wakeup call for Microsoft. I'd love to see Borland get the Os/2 source code from IBM, package the compiled OS with Borland's Delphi (or even C++) and give it away. Yes, GIVE THE OS AWAY - including all of the associated APIs. (I'd still hold back the actual source code for the OS - after all, somebody has to keep things compatible - look at the fragmentation of Linux and you just might agree with me.)

There would be a stampede of Visual Basic developers, open source champions and (most importantly) schools, teachers and students that would begin writing for this "new" platform.

The catch? They'd need to promise to ALWAYS provide backwards compatibility for 2 versions. Keep the changes limited. Value stability and compatibility over new and "shiny". And don't copy your competition like Microsoft's .Net has tried to copy JAVA. Actually innovate and lead - don't just use the words as a slogan to skirt lawsuits.

Borland could sell development tools (compilers and components) for a FREE OS that was years ahead of Microsoft years ago and make a killing. They've seen what people want and will use - simple tools like VB. Most "programmers" don’t write code for a living, they write code to make making a living easier. Even with all of its flaws, people loved VB.

When something works, and the originator abandons it, usually another company will come along and use the tried and true formula to make themselves wealthy. Well......Microsoft abandoned VB. It was simple. Non-programmers could hack out tools to make their jobs easier. The 3rd party component market for VB was a huge money-maker and it made the "programmers" happy too, because it made development even easier!

If only somebody with the infrastructure in place for such a task would step up to the plate...a home run is virtually guaranteed.

A Borland or an ORACLE would mop Microsoft up within 5 years if they simply did not adandon their user base as Microsoft is doing in favor of what the Redmond programmers want (and will, no doubt, get).

HEY BORLAND!!!! YOU LISTENING?

Let's face it. Microsoft wrote .Net for Microsoft......no one else. They wrote .Net to help themselves reach their dream of all Microsoft products as services by the year 2010.

Just step back and look at .Net. It's a great first stab at writing subscription software. And, they did a great job of selling an unfinished product to the world's largest beta test group. But the interface still sucked and remoting didn't deliver outside the intranet......so here comes Avalon.

You see, Microsoft knows that applications that look like crap sell like crap. That's why they are doing the whole Avalon thing. Their subscription-based software HAS to look as good as desktop software and that's what Avalon is for.

Abstraction of the desktop is NOT the goal. You'll still have to buy the latest, greatest Microsoft OS to enjoy the freedom of being tied to a new desktop with a new (surely to be replaced soon) framework like Avalon, or its replacement.

Hey! Maybe this OS programmer torture rack will have a window next to it! I can hardly wait!

But, NEVER forget, .Net was (and is) not about you, or me, or any other everyday developer. It's about Microsoft and their control of your desktop. It's about a company with $50 BILLION in cash reserves saying "That's not enough." Plainly put.... .Net is about greed and losing touch with reality.

Funny thing.....greed. When it takes over.....well, that's when you start LOSING money. You start making decisions that put the company before the customer. And, ever so slowly, the customers notice....and begin trying new things - at your competitors place of business. And, by the time you notice what you've done, you've destroyed the loyalty and faith that your customers had for you.....along with your bottom line.

And, all the Dean-ish "Developers! Developers! Developers! Developers!" rants in the world won't bring them back. After all, they never did listen to what you said. They were too busy watching what you did.

As for losing touch with reality.... Microsoft has become like the TV and movie "stars" that we are all so familiar with today. They live so far removed from everyday reality that it begins to affect their ability to think rationally. They've surrounded themselves with people whose very livelyhood depends on being liked enough to be kept around and given a paycheck for agreeing that the star's every idea is a stoke of genius.

Then they wind up on the front pages of the tabloids....and we all laugh at the people we worshipped yesterday.

It's true. Microsoft developers have created their very own Neverland.

If we all developed Microsoft operating systems and sold Office as a service, perhaps .Net, Avalon and WinFX would be good things.

We don't.

They aren't.

Well......you know what they say......"What goes up...."

(BORLAND! Call me!)

Why aren't .Net updates automatic?

2005-01-18T22:07:00.000-08:00

Ok...Its taken me a while.....but here it is.

I'm really very interested in why Visual Studio .Net updates aren't automatic. I know....if you change something midstream in a development environment it can have unpredictable results.

I've fought this battle with network administrators many times. I've always won, but it was never pretty. I still fail to see why network admins don't just put the developers on another segment of the LAN and leave them to do their thing.

But, that's not what this blog is about. It's about Visual Studio .Net updates and why they aren;t automated.

Let's even keep things simple and say that VS.Net updates cannot be completely automatic because they may change development systems mid-cycle and screw up some projects. Very well....then would it hurt Microsoft to send out emails to the registered users of VS.Net telling them when a new hotfix was available? How about a popup box alerting developer to new hotfixes for their version of .Net and offering a simple download manager online like Windows Updates?

It's not like they don't know who we are or that a hotfix has been made available. MS could save themselves some time and just purchase KBAlertz. KBAlertz is a free alert system to new Knowledge Base articles targeting Microsoft products - including the .Net framework. I highly recommend all .Net developers to sign up (http://www.kbalertz.com/Default.aspx).

You'd be amazed at how many .Net framework alerts are issued. It seems like one every other day and covers all 3 versions (1.0, 1.1, 2.0) of the .Net framework. You'll see what I mean if you sign up to get .Net framework alerts via the KBAlertz website.

Ok.....Microsoft can't do automatic updates (not even with an "install later" feature) and they can only send spam to our emails....not important security updates to the .Net framework. But, the creamy goodnes doesn't stop there.....

Once you find a hotfix (through much searching or a KBAlertz message) you can't download it. That's right! Microsoft, more and more, is requiring developers (whose time is stretched to the breaking point already and who must compete with much cheaper labor offshore to get projects done on time and within budget) to stop whatever they are doing and CALL Microsoft to get the hotfix!

What the hell is that about? It can't be to stop piracy of the .Net studio....a simple passport check for authorized purchasers could do that.

What would be the reason to not allow .Net developers to download the hotfixes from the Microsoft Knowledge Base articles that describe them?

I have to admit that I really have no idea. If you do, please let me know.

Here we have the premire Microsoft development tool (Visual Studio .Net) that doesn't offer automatic updates (something almost every upscale freeware package does now), does not notify it's purchasers of hotfixes that may not only affect their development, but also their company and their very ability to feed and clothe their family AND, once the wretched developer finds out that there is a problem and an available hotfix, the hotfix is hidden behind a wall of voice menus instead of just a link on the Knowledge Base Article.

This makes developers that want to maintian up-to-date systems call Microsoft almost every other day!

Why the hell would they do that? If you know, please tell me.

Have we traded DLL Hell for .Net version hell?

2005-01-06T02:11:00.000-08:00

As I set out to write my next software project, my chosen platform is the 1.1 version of the .Net framework. I have chosen it because it is the version supported by Microsoft. And, I like Microsoft's platform and their products. I think that Microsoft has the most user-friendly OS and applications available.

This is not to say that I see no problems with Microsoft platforms or applications. Take .Net for instance...

The .Net platform has been stated by Microsoft to be it's selected toolset for moving forward. Microsoft has stated that .Net will be in every future operating system that is currently under development. .Net is becoming core to technologies like SQL Server too.

Seeing as how .Net is at the core of all new development at Microsoft, I can't, for the life of me, understand the .Net framework not being an automated download of all Microsoft operating systems (at least the systems that haven't been retired which includes XP Pro, XP Home and Windows 2003).

With Microsoft pushing .Net as the next generation development platform for the Windows environment, you'd think they's want every user to be able to run .Net applications. Oh sure, you can download the .Net framework free from Microsoft, but how many regular users know how to do that?

Yes, I know....developers can include the framework in their setups. But, there are sometimes problems with the .Net install when not installing on a "clean" machine. Are developers supposed to do Microsoft's .Net support too?

Then there is the question of bloated installations....especially if you put web-based installations on your website. Forget that Microsoft is asking for a free ride for their 23+MB framework on your installation CDs and simply consider the implications of NOT being able to distribute your application via the internet to your customers because they don't have a high speed connection to download the bloated install of .Net framework plus your application.

50% of US customers still do not have access to high speed internet connections. Can you imagine waiting for a 23+MB install over a modem? I can, and it makes me shudder.

There is a really neat feature of .Net that allows you to publish an application (of limited use if deployed over the internet because of security restrictions) on a server and include it's needed DLLs in the same folder. When the executable is run, it only downloads the parts of the program it needs to run. If it doesn't need a DLL to perform a function that the user is attempting, it just doesn't download it. Why doesn't the .Net framework work like that?

Is it really too much to ask to place a small package in each .Net executable that looks for the .Net version and classes on the local machine and downloads what it needs (and only what it needs) of the .Net framework directly from Microsoft before running?

This would distribute the .Net framework right from Microsoft (with all of the latest patches and hotfixes) while preserving bandwidth by downloading only the needed portions of the framework and you could still distribute your .Net applications from your website.

Yes, I heard you. So .Net will be shipped with the OS, huh? Well, what happens when a newer version of .Net is released? Do you wait 2+ years for it to be on most desktops before using it? That's what it will take to wait for the people to upgrade their OS in the best of scenarios. This very scenario is playing out with versions 1.0, 1.1 and 2.0.

This brings me to the question at hand. Since you may be developing in version 1.0, 1.1 or 2.0, you still have to make sure that your users have the version of the framework that you wrote your code in installed. If you don't ship the .Net install with your installation package, you really can't be sure the customer will be able to run it. And, if you do include the .Net framework in your installation package, *poof* there goes internet distribution.

Have we swapped one hell for another? Not that I even believe there was a DLL Hell...but that's another discussion altogether.

I have found a solution that works for my development shop. It's a little pricey, but if you make a living distributing applications, it is well worth it.

This solution will take your executable (.Net, VB or C++) and all of its dependencies and wrap them all into a single executable. The neat thing is that it even includes the portions of the .Net framework needed to run your executable inside the executable it creates. So, there's no need to distribute the whole .Net framework.

If you use DLLs, your program always uses the right DLLs because they are safely tucked inside your wrapped executable.

Even .Net code is safer because the IL disassemblers can't decode the .Net application inside the wrapped executable! This stuff is just plain cool! (This was my biggest worry about distributing my .Net code. Now I distribute .Net applications freely without worrying about decompilers or losing sales because someone copied my hard work.)

You can distribute database files (also secured inside your wrapped executable) and even do licensing of your application with the built in functionality of the wrapper.

It saves bandwidth too. A simple, single form application with the .Net framework installation will weigh in at 25+MB in an ordinary installation package. In my testing the same application wrapped for distribution weighs in at only 6MB. Small enough for modem distribution.

The wrapped executables can even run with no installation whatsoever! The wrapped executable creates a virtual filesystem, virtual registry entries and has access to all of the physical files and registry entries also. When the app closes there are no residual registry entries or application files/directories - not even temp files. (Of course there are options to place real files in real directories and leave them there if you need to....like for an updatable database application or image editing.)

Since your customers don't have to install .Net to use your application when it is wrapped, and your DLLs are always secure inside your wrapped executable, you will cut your installation support issues to almost nil. The customer simply double clicks your wrapped executable and the application just runs! You gotta see it to believe it.

The drawback? It's kinda pricey for freeware app devlopers. You need to be making money from your apps to make it pay off. Their pricing model is currently under review. They are trying very hard to come up with a licensing model that works well for both large and small development houses. IMHO, it pays for itself in short order if you publish software for a living (which I do).

The wunderware I speak of is Thinstall. You can read all about it at www.Thinstall.com.

Nope....I'm not paid to advertise their stuff. (Not yet anyway.... :) ) I just really love this software! Why can't Microsoft do this?

Damn! What a concept! A development suite that wraps absolutely everything the application needs into one secure executable. No more DLL hell. No more .Net version issues. No more installation issues.

If Microsoft put this into the .Net development suite (a plug-in for .Net is scheduled in the 3.0 release due out late this year) THAT would be a development suite!

I'm not the only one that likes it. Almost every branch of the armed forces uses it along with NASA, Boeing, GE, Lucent....well, you get the picture.

The one endorsement that impressed me the most was the one from Alan Cooper (the "Father of Visual Basic" and author of "The Inmates Are Running the Asylum"). You can read it for yourself at http://www.thinstall.com/help/?customerquotes.htm.

In my humble opinion, .Net framework verisoning is the next "DLL Hell". Thankfully Johnathan Clark and his staff are there with Thinstall to help.

If you do decide to buy it (like I did) mention promotion code jim__hubbard@hotmail.com and Jonathan will knock 5% off the price.

Next....."Automatic downloads in the 2003 .Net Studio. Why aren't they automatic?"