December 2003 - Posts
Since working with EnterpriseServices (ES), I have found some of the nicer features that are available through COM+ 1.5 (on Windows XP and Windows Server 2003 ONLY). A couple of noteworthy options:
1. COM+ Services without Components. I can implement select features of COM+ (such as transactions) without all the overhead of invoking a full-blown .Net class derived from ServicedComponent. I am still determining how useful and viable this is in a large distributed environment.
2. IsPrivateComponent. A property (attribute) that allows me to mark a component as private (within a Server application). This private component is only callable within the Server application. Previously, in COM+ 1.0 (Windows 2000), all components had to be public to have access to COM+ services, which meant that these components could be activated from other applications.
Some other COM+ 1.5 specific features are noted in the .NET Enterprise Services and COM+ 1.5 Architecture article.
Over Christmas break, I spent a lot of time experimenting with EnterpriseServices (ES)/COM+, in particular with Distributed Transactions. Within our team, there were some questions that came up last week regarding ES:
1. Tim Ewald, in his excellent COM+ book, describes the ideas of “configured” components and “nonconfigured” components. It would seem that a configured component (installed in the COM+ catalog) can call a non-configured component and can (possibly??) enlist the nonconfigured component within a COM+ transaction. How does this work with ES? Answer: In testing with ES, you don't necessarily need to have a class implementing the ServicedComponent interface, but you do need to reference the System.EnterpriseServices namespace in order for the Context, Activity, and Transaction to flow to the “nonconfigured” .Net component. Noting Tim Ewald's follow-up article, I did find this:
It is interesting to note that CLR objects behave exactly the opposite of how COM objects behave with respect to COM+ context. With COM, calls to an object are always intercepted by default; all objects are context-bound. A COM object can only be context-agile if it aggregates the freethreaded marshaler (FTM) and is not the first object created in a new COM+ context (that is, it is not the distinguished object), in which case, calls to it will not be intercepted. The benefit of this new approach is that it reduces interception overhead by ensuring that calls will be pre- and post-processed only when absolutely necessary. Specifically, if an instance of a configured class returns a reference to an instance of a nonconfigured class (an ADO. NET DataSet object, for example), calls to that object will not be intercepted. And the DataSet object doesn't have to do anything special, it just works this way.
What I saw was that when I referenced System.EnterpriseServices in the assembly metadata, then I could “reach up“ and grab the ContextId, ActivityId, and TransactionId within a class method that was not deriving ServicedComponent. Was that method in a transaction at that point or not?
2. Is it possible that a method could opt in or out of a distributed transaction? Answer: Yes. Distributed transaction enlistment can be automatic depending on the root of the transaction (with declaritive transaction support). But, within the connection string, the option “Enlist=false” can make sure enlistment doesn't happen. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconenlistingindistributedtransaction.asp for more interesting details.
These are just a couple of items. I plan on writing more regarding some of the gotchas we have found plus problems we are still puzzling through.
Scott Koons posted an interesting comment to my earlier post:
Am I alone in thinking that there NEEDS to be a "Effective C#" and "Effective VB.NET", maybe just a "Effective .NET" series?
As far as I can tell, among the MSDN Patterns and Practices books and articles, DevelopMentor .Net books, the Addison-Wesley .Net series books, and many other excellent .Net resources, there are some very noteworthy tidbits of .Net advice. But, no one has yet put together a concise "Effective-style" book for .Net like Scott Meyers did for C++ and STL.
I, for one, have been keeping a collection of notes on the various bits of information I find in these resources. I keep it in a standard notebook of notes, noting where I found the reference, when I found it, and if something else I have read or found through experimenting has now nullified that information. It would be nice, though, to have a concise collection of this information in book form.
Sam points to NAnt 0.84 Final being released. Along with that, I found that the latest NAntContrib Project has been released as well. For tips on getting started with NAnt, check out a previous post where I describe my own experiences with the pre-release of NAnt 0.84.
Update: One follow-up to that post is that I found you do have point to explicit drive/file locations for GAC'd assemblies -- NAnt (really, its csc.exe that NAnt is using, so this applies to the limitations of csc instead of NAnt) is unable to reference assemblies stored in the GAC directly (unless they are also stored, as some System assemblies are, in the \WINDOWS\Microsoft.NET\Framework\v1.0.3705 area).
If you have previously been a C++ wonk, you probably know Scott Meyers
as a household name. He wrote excellent books on Effective C++
and Effective STL
in the 90s, and his writing style has influenced others, including Don Box
who wrote Effective COM
. Now, Scott has written a great article on his own experiences in writing and getting books published titled Advice to Prospective Book Authors
. Even if you are an armchair book author (“one day, someday, I will write a book!”), you owe yourself a read.
Last night, I had the opportunity to speak to the New Hampshire .Net Users Group about .Net Security, in particular speaking about User (Role-Based) Security and Code Access Security. My emphasis was on how .Net addresses these important issues in security:
Authentication: Who are you?
Authorization: What are you permitted to do?
While doing some research for this presentation, I found this nice little book from the Microsoft Patterns and Practices Group called Designing Application-Managed Authorization (you can download the PDF here). This book details some of the ideas I spoke about last night regarding use of the Principal and Identity objects to validate a user (Authentication above) as well as various methods to enforce what that user is able to do (Authorization above).
The NH .Net User Group site has been updated with the meeting information for next Thursday as well as some great links on .Net Security:
6:00PM Thursday, December 18th, 2003
Wang Auditorium - Boston University Corporate Education Center
Featured Guest: Robert Hurlbut
Topic: .NET Security Best Practices
MSDN: Code Access Security in Practice
MSDN: Code Access Security...Enhance Client-Side Apps
MSDN: Security in .NET: Enforce Code Access Rights with the CLR
MSDN: Unify the Role-Based Security...with .NET
I will be speaking to the New Hampshire .Net Users Group, Tyngsborough, MA next Thursday (December 18, 2003) on the topic .Net Security Best Practices. A big thank you to Sam for recommending me to Jim for this opportunity. Here is a summary of what I will be covering:
Within the .Net Framework, two complementary forms of security are present: User (Role-Based) Security and Code (Access) Security. User security answers the questions,
“Who is the user and what can the user do?” while code security answers the questions “Where is the code from, who wrote the code, and what can the code do?”. This presentation will give a practical overview of both forms of .Net Security as well as best practices for using .Net Security.
If you are in the area, stop by and say hello.
My friend Andrew has been doing a lot of research lately to find more information on Rotor beyond the excellent Rotor book (Shared Source CLI Essentials). Yesterday, he posted a wiki link to a great architectural resource for Rotor: Software Architecture of 'Rotor' CLR.
I've said it before, and I will say it again, one of the BEST ways to learn what's going on under the CLR is look at Rotor code.
Lars Bergstrom wrote an article for MSDN a few months ago called “Developing Software in Visual Studio .NET with Non-Administrative Privileges” and it looks like it has been updated this month. Do yourself a favor, and read this article.
Over the last few years, I have been a big believer in developing software as a non-Administrator. I followed Keith Brown's excellent advice on how to set up your machine correctly, and have continued to do so with each new OS or machine. The key is to only run as Administrator (using the “Run As“ feature) when you need to install software or various other administrative (hence, the reason why the user is called “Administrator”) tasks.
On my laptop, I run two OSs, Windows 2000 Server and Windows Server 2003, plus a Virtual PC with Windows XP Pro, and in all cases, I set up strong passwords, rename the Administrator, and run with an everyday normal, non-privileged user. With this mode, I have found, like Lars and Keith above, interesting ways to do secure tasks, especially with distributed .Net application development lately.
As Keith mentions, its a “lifestyle choice“ to develop this way. You make a decision to run as a normal, non-privileged user to help yourself learn about security on the platform as well as how to write better, secure code. Most users who work with our software are usually running as non-Admins, and can hit the security wall hard if we are not careful.
Plus, a big question for developers I always want to ask: “Do you need to be an Administrator to check email in Outlook?”.
More Posts Next page »