The buzz was all around VSLive last week about Microsoft
patenting the .NET Framework API. In fact, an eWEEK reporter asked my opinion
and this is what I said:
I’m no patent attorney, but in examining
the patent application, it looks to me as if they’re claiming a patent for
the entire .NET Framework, which comprises the classes that a .NET
programmers uses to get anything done. My understanding of the patent laws
says that Microsoft has every right to do this, since they invented it. The
reason for them to do this is so that they can maintain control of its
implementation. Hopefully Microsoft will grant a royalty free license to all
implementations of the CLIECMA standard, which makes up a large percentage
of the .NET Framework, or that standard will be worthless.
Even if they grant such a license, projects like Mono are still vulnerable.
They plan on implementing even the parts of .NET that aren’t standardized,
like ASP.NET and WinForms. This would allow Windows programs compiled
against .NET to run under Mono on Linux, providing a single API for
cross-platform applications. This has been tried and failed in the past as
recently as Java, but I had hoped that the Mono guys could make this work.
When Microsoft is granted this patent, they can shut down the
non-standardized parts of Mono whenever they want. That’s good for Microsoft
share holders, but it’s not good for 3rd party developers that want to write
cross-platform solutions.
What I should have added is that as
far as I know, Microsoft hasn’t ever enforced its patents. Apparently they keep
them for defensive reasons only. Or, they could be waiting ’til they have a
critical mass of patents, enforce them all at once and win the game of Risk that
they’re playing with the world. : )
Here. A bunch of kids gather in a real-world like setting to design an app, only consulting an actual software engineer after the spec is done. Not only does the core app sound cool, i.e. groups of contacts that play/chat together in an online environment, but the way they designed it sounds cool, too. I'd like to grab a set of my customer base and hang in a trendy Seattle downtown warehouse for a month, too, but my customers are all too old to get away for that long. : )
Here. From Juan Esteban Suarez: Academic project. Free download from www.doteasy.addr.com.
Abstract: "dotEASY" is a Visual Studio .Net Add-in that evaluates C# source code and performs "advices" in order to improve software quality. The configuration and programming of the "advices" is invisible to the developer, the tool’s final user, who only requests for code evaluation. A new "advice" can be created defining metrics, thresholds and optionally programming validation classes and execution classes to automatically modify the code. The export and import capabilities allow one person to create an "advice", which can be configured and exported, so it can be used by many other people.
From David Taylor: I just read Chris Sell's "Distributed .config Files with Smart Clients" article:
http://www.ondotnet.com/pub/a/dotnet/2003/01/27/ztd.html
Here is another problem I just came across. I often use System.Diagnostics.Process.Start("http://www.sellsbrothers.com") to launch a website (or mailto, etc). However when deploying a simple URL shortcut to the actual application (on a web server), the assembly gets hosted by IEEXEC.exe. The problem is that the Process.Start method then returns a file not found error! I did get it working by directly invoking Internet Explorer, but I needed to know it's directory from the registry because it is not always in the path (and there were some other strange behaviors). So I have ended up using a minimalist setup.msi file that leaves a 5-10 line Loader.exe program on the users computer which in turn loads the assembly from the web server. That way it is *not* hosted in IEEXEC and Process.Start works as expected.
