Carl is a fervent supporter of VB.NET and dispels all sorts of myths about the language. Carl told Jeff he didn’t agree, but didn't start a debate. Jeff commands a great deal of respect in the .NET community, as well he should, but I think the truth is somewhere in the middle.
I don’t think the C# code from a competent, professional programmer would show a noticeable difference when compared to the performance of the same implementation written by a competent pro in VB.NET. When it comes to the hobbyist who doesn’t know what “option strict” does, (and doesn’t care) however, this is where you see the spread.
About one year ago I met a pharmacist who wrote an application in ASP.NET. The application tracked drug-drug interactions for patient safety. It was a great implementation of the pharmacist’s domain knowledge. The application worked. Would I have shrink-wrapped the code and put up for sale? No. Was it scalable? No – but, the point is, this fellow was putting his expertise to work, and his expertise wasn’t in building a scalable web site.
If someone put this application through a stress test, they might conclude that the entire .NET platform isn’t scalable. Just like political sound bites – you sometimes have to put a piece back into context before making a judgment. Perhaps this perceived performance difference isn’t really because of the different compilers, but because there is a significant percentage of VB.NET developers who don’t change the default setting of option strict (off by default). Late binding is a drag.
I do think there will be a divergence in the future between C# and VB.NET if VB.NET continues to layer higher levels of abstraction on top of the base class library (like the My keyword in 2005). As long as you know the underlying framework, it still shouldn’t matter much in the time trails.
Let’s say the sales and marketing department has decided the company is about to build version 3.0 of an amazing product: FooBar. Sometime thereafter, someone checks in a file named FooBar3.cs into source control.
I see two problems here. First, source control software, also known as version control software, will manage versions all by itself. Instead of putting version numbers in the file name, leave version numbers to the tool. When it comes time to associate a file version with a specific product release, I use the tagging / labeling functionality of the tool, and avoid potentially confusing conversations like:
Is FooBar3.cs checked in to build FooBar 4.0?
Does FooBar 5.0 still have FooBar3.cs?
This reminds me of an RFC on machine naming conventions (which I can’t find now). It suggests not giving the computer a name like UP or DOWN, because technical support will get calls like:
Is DOWN up?
Is UP down?
The second problem is letting a product name into the source code. Product names belong to marketing and sales. Product names are subject to change with the phases of the moon. Today the product is “FooBar 3.0”, tomorrow the product is renamed “Fabio 2005”.
Code names - really cool code names - like “Death Star” and “Predator”, belong to engineering. No one can make you change a code name. Well, unless you are Apple. In 1993 somebody at Apple decided to use “Carl Sagan” as a code name. Sagan’s attorney sent a letter to Apple asking them to stop. Someone at Apple then decided to change the codename to BHA – short for ‘butt-head astronomer’. Sagan then filed suit for emotional distress.
My advice then is this: don’t use version numbers, product names, company names, or the names of humor-impaired scientists when naming your project artifacts. Still, you might want to check with your lawyer first.
Designing an authentication and authorization scheme for software in the healthcare market means sitting down with people and understanding their interpretations about the sticky pit of legal and regulatory goo they live in. Everyone has a different opinion about the U.S. Health Insurance Portability and Accountability Act of 1996 (HIPPA). One of the objectives of HIPPA was to guarantee the security and privacy of health information. The effectiveness of HIPPA on the privacy of a health record is debatable, but is has certainly been a boon to consultants and companies offering to bring a healthcare organization into compliance. Some places want software to audit every user move, others just want to disable USB ports so nobody walks out of the place with patient records on a jump drive.
I’m all for privacy, but I do find it frustrating from a professional angle when trying to sort out what people want and what the ‘right thing’ is. It’s also sadly amusing to watch to what happens when legislation and regulatory agencies collide.
For example, the Occupational Safety and Health Administration (OSHA) requires employers to keep a list of injury and illness reports with employee names, and to make the list available to employers, former employers, and employee representatives (like the AFL-CIO, a labor organization covering many industries). HIPPA leans towards hiding names, OSHA wants names on the logs. So what do you do? One solution is to ask for a clarification from the Director of the Directorate of Evaluation and Analysis at OSHA (via hippablog). Titles like these make me wonder who the libertarian candidate is this year…
CreateProcessWithLogonW is one of those tricky APIs that doesn’t pick up and move well from one environment to the next. Unfortunately, there is no way with .NET 1.1 to start a new process under alternate credentials without PInvoke. A spawned process always inherits the token of the creator process, so even if a thread is impersonating when it calls Process.Start, the new process always has the same identity of the current process. The good news is that Microsoft makes it easy in .NET 2.0.
Always approach launching a process on the server with caution. Launching an interactive process or a process under different credentials from a service should usually be avoided. In addition to overcoming all the privilege checks, you also have to deal with windowstations and desktops – not an issue in WinForms programming.
One little note about the code: the call to CreateProcessWithLogonW will fill the ProcessInformation structure with two IntPtr members representing Windows HANDLE types - these should be properly cleaned up with CloseHandle.