Microsoft is hiring Verissimo de Oliveira, the founder of the Castle Project, which has one of most popular Dependency Injection (DI) frameworks for .NET, Windsor.
From this eWeek article:
In addition, Microsoft's hiring moves have reflected a move toward more "open"-minded individuals. For instance Hamilton Verissimo de Oliveira, founder of the Castle Project, recently said he will join Microsoft as project manager of the MEF (Managed Extensibility Framework) team. MEF provides developers with a tool to easily add extensibility to their applications and with minimal impact on existing code.
I would say Microsoft is serious about DI, no?
I was finally able to attend the June Atlanta Cutting Edge .NET UG meeting yesterday. Shawn Wildermuth gave a great presentation the on VS2008 SP1 data technologies: ADO.NET Entity Framework and ADO.NET Data Services (Astoria).
Shawn's recommendations were:
- The Entity Framework (EF) is for enterprises with a large, stable data store
- The most important part of EF is the Entity Data Model (EDM) itself. It is very robust in the mappings it can handle and the extensibility points available.
- Enterprises should hold off and see whether Microsoft and third parties will invest in the EDM. He recommends nHibernate for now.
- ADO.NET Data Services (DS) are only useful for Internet (not intranet or, presumably extranet) where data security is not an issue. His biggest concern was the serialization overhead. I basically interpret that to mean that you should not use DS for essentially 2 tier development.
Interesting points were:
- Shawn was unsure whether EF exposes the model to consumers. I will have to investigate. He did believe, however, that the model is extensible.
- They don't have model/db generation from objects, but they DO have round tripping between the model and the data store.
- As discussed in the July 2007 MSDN article on EF, the Designer is lightweight and you should prepare yourself to be designing in angle brackets for the 1.0 release at least.
- In 1.0, at least, EF will not support Unit of Work and POCO objects. It will support, however, what they call IPOCO, which means the standard data binding interfaces of INotifyPropertyChanged and INotifyCollectionChanged.
- EF can only model/update a single database in 1.0
- DS is a simple proxy layer (my words) over any LINQ source (IQueryable).
- DS provides a command line code code generation step that provides a client side LINQ interface for .NET and Silverlight and a LINQ-like interface for ECMAScript. Nice. Anyone have a MSBuild task for it yet?
A common question in my mind is how to correctly refer to the various editions of Team System in a short form. Since the full name is so long:
Visual Studio Team System 2008 Database Edition
for example.
Gert Draper, the architect on the Team Database Edition team, suggests using VSDB for the Database edition and VSDE for the developer edition. However, he also uses VSTS-DB. Team Database Edition is used by the install program.
So using the names from the product page, let's create a naming convention list:
| Full Name | Short Name | Long Acronym | Short Acronym |
| Visual Studio Team System 2008 Team Suite | Team Suite | VSTS-STE | VSTS |
| Visual Studio Team System 2008 Architecture Edition | Team Architecture Edition | VSTS-AE | VSAE |
| Visual Studio Team System 2008 Developer Edition | Team Developer Edition | VSTS-DE | VSDE |
| Visual Studio Team System 2008 Database Edition | Team Database Edition | VSTS-DB | VSDB |
| Visual Studio Team System 2008 Test Edition | Team Test Edition | VSTS-TE | VSTE |
| Visual Studio Team System 2008 Team Foundation Server | Team Foundation Server | VSTS-TFS | TFS |
Any suggested alterations?
xUnit.net 1.0, just released, is an update to NUnit 2.0 that encodes some unit testing best practices and leverages .NET 2.0 technologies like generics. Intro here and download here.
If you don't have Visual Studio Team Developer Edition, consider using xUnit.net for your development project unit testing.
It is common to use SQL Scripts to create or initialize a DB from a setup program. For example TS DB Pro integrates with SQLCMD variable syntax.
One issue with this is that an MSI may need access to SQLCMD.exe. I've picked up the bits from a local SQL Server 2005 installation, but you don't have to do that. Feature Pack for Microsoft SQL Server 2005 provides a redistributable package for just SQLCMD:
Microsoft SQL Server 2005 Command Line Query Utility
The SQLCMD utility allows users to connect, send Transact-SQL batches, and output rowset information from SQL Server 7.0, SQL Server 2000, and SQL Server 2005 instances. SQLCMD is a replacement for ISQL and OSQL, but can coexist with installations that have ISQL or OSQL installed.
Note: Microsoft SQL Server 2005 Command Line Query Utility requires Microsoft SQL Server Native Client, also available on this page.
Audience(s): Customer, Partner, Developer
Assume everything is implicit unless you are told otherwise.
I generally consider it bad practice to have encoded fields in tables and implicit rules in objects. You should generally make your rules explicit by creating calculated columns, views, & etc for databases and creating properties for classes that encode the rules.
Example:
public bool IsBest { get { return rating >= 3; } }
According to Charles Young you simply need to install .Net 3.5 and change any relevant assembly references to .Net 3.5 versions. Of course, you can use the new language features such as the LINQ query syntax. But you could use the extension methods as regular static methods, for example.
However, in Scott Gutherie’s blog entry on the release of VS2008/.NET 3.5 this comment specifies a problem with upgrading the Ajax code. (Or maybe he did not upgrade the Ajax code.) From Scott’s reply they are not expecting any issues with the upgrade. There are tons of comments to this blog entry I may be work your wile to peruse the list to see if there are any other potential gotchas.
Daniel Moth affirms that the “Red Bits” of 3.5 are just the SP1 for .NET 2.0 and .NET 3.0.
A word of warning from Rick Straw: From an administrative standpoint the CLR is still at v2.0.
The Microsoft PowerShell team published an important standard: Microsoft Command Line Standard. As PM Jeffrey Snover explains in his post, the document is divided in three sections:
Snover's core recommendation is, if course, to create PowerShell Cmdlets so you can easily support this standard.
K. Scott Alan has a great, concise introduction to the System.Workflow.Activities classes.
I'm creating an application service that manages multiple AppDomains for worker threads. You have to do this in just the right way to get it to work with Visual Studio Team Edition unit tests.
Summary:
Background:
When you manually create an AppDomain using AppDomain.CreateInstance the defaults for settings are the executable's values. This is fine for a normal application. However, for unit tests, your code is running in an AppDomain other than the executable's domain, so that all the DLLs etc. can be loaded (NUnit works the same way). When you create instances in the new AppDomain, the type resolver is suddenly looking in the folder of the unit test harness executable, rather than in your test assembly's folder. You fix the problem by creating an AppDomainSetup instance and setting the ApplicationBase path to your own AppDomain's value. If that AppDomain is going to access your configuration file, be sure to also set the ConfigurationFile property to your AppDomain's value, also. The example I saw on the Team Test forum also set the AppDomain's Evidence to match the current AppDomain's also.
Example:
AppDomain currentDomain = AppDomain.CurrentDomain;
AppDomainSetup currentInfo = currentDomain.SetupInformation;
string fiendlyName = "FriendlyName";
Evidence securityInfo = new Evidence(currentDomain.Evidence);
AppDomainSetup info = new AppDomainSetup();
info.ApplicationBase = currentInfo.ApplicationBase;
info.ConfigurationFile = currentInfo.ConfigurationFile;
AppDomain domain = AppDomain.CreateDomain(fiendlyName, securityInfo, info);
References:
It looks like Eric Meijer has taken retiring the the four tenets to heart. In his CTP announcement blog entry, Meijer states that Microsoft's project code-named Volta, service boundaries are crossed by decorating a class with [RunAtOrigin] and configuring for the origin on the application tier (disclaimer: I haven't yet looked at the implementation details of Volta).
This does not bode well for the contract-first folks and doesn't seemed to be aimed at long-lived commercial software. That focus would fit in well with Linq to SQL's target audience though.
I guess life is a mashup.
In a large business services enterprise there may be several lines of businesses that have swiftly changing business rules. Windows Workflow Foundation (WF) was designed to provide a way to implement business processes and rules without coding.
Before WF came out, I saw several lines of businesses at Aon using InRule for this purpose. Now, InRule has released InRule for Windows Workflow Foundation.
Here are the bullet points from their marketing page:
- An authoring environment that enables both developers and non-technical users to easily author, test, and maintain business rules the WF rules engine.
- Capabilities to extend the Windows Workflow Foundation rules engine, including decision tables and 90+ built in functions.
- A Rule Catalog to manage rule check-in/check-out, versioning, and permissions across systems.
I would encourage any enterprise with a strong Windows stack in some of their business unites to consider InRule as a rules engine standard.
They support WF alone and BizTalk Server, so it can scale with the size of a project. It has it's own version control system and deployment model. I can only hope it's better then Crystal XI. Regardless there will be work in that area to integrate rules deployment with your software releases.
With the release of Visual Studio 2008 and TFS 2008, there is now even less of a reason to place any revision comments in the code base. Once upon a time all reputable source control systems had a keyword expansion feature that included the revision comments for all revisions in the source file.
Version control managers de-emphasize this feature because users should use the repository for getting comments, which is tooling accessible and if readers rely on the code base for the revision comments, developers are less likely to provide good revision comments.
The keywords feature is totally removed from TFS. I think this is a mistake (though welcome because keyword support is a pain). I have heard that there are some compliance requirements that comments for code changes must appear in the code base. Of course the requirement itself is from the dark ages, but nonetheless, it should be supported.
Apart from those that must support the above requirement, some development teams prefer inline revision comments (i.e., // RKK 03/02/98: Fixed bug 2937 ) so that they know that a certain area of code has been "touched," since, as we all know, fixing one bug begets another and finding who touched a line of code in a version control system usually requires a binary search of diff'ing to find the offender.
TFS 2008 and VS2008 fix this problem. The new annotations feature permits one to easily see exactly who updated each line of code with a quick link to revision comments.
This feature has been provided with the TFS Power Tools for a while now. However with its integration into the IDE, it is a simple case for version control managers to make to prohibit the use of file header and inline revision comments.
Buck Hodges shares how to solve these five issues in this very useful post.
- Issue #1: Team Build service account does not have the required SQL Server permissions or cannot connect to SQL Server
- Issue #2: Values for TargetDatabase, TargetConnectionString, or DefaultDataPath are missing or incorrect
- Issue #3: The New Build Definition dialog does not provide a “Default” configuration option
- Issue #4: The Deploy target is not invoked when built via Team Build
- Issue #5: Database Unit Tests cannot find database project files, data generation plans, or the database instance(s) to be used for running tests when run via Team Build
IDesign has updated their C# Coding Guidelines. (download). A previous version can be found in Juval Lowy's Programming .NET Components.
Whatever you say about the the configuration functionality of Enterprise Library, one thing that won't be said is that it is straight forward. In fact, they created the Application Block Software Factory to help you through the five classes necessary to create the runtime configuration classes and a whole other set of classes for the design time experience.
Developers of small or local frameworks may not be willing to tie themselves to that horse just to set a few values in their web.config file.
Of course .Net 2.0 introduced the Provider Model, embodied in the System.Configuration.Provider.ProviderBase class. Unfortunately it's rather low on the workability scale itself.
This blog entry, by Phil Haack, shares a small generic library that will lower the bar to entry for making custom providers.
Back in 2004 Microsoft encouraged distributed developers to base their work on ASP.NET Web Services (ASMX) architecture rather than .NET Remoting. From that moment I knew that .NET Remoting was moribund and should not be pursued for new development.
Some folks however preferred Remoting because it did not have the IIS overhead that ASMX did. I would say that unless not having IIS was a requirement, they were mistaken.
Clemens Vasters summarizes a Microsoft whitepaper that compares performance between the different MS technologies. The results? WCF is
- %25 - %50 faster than ASMX
- %25 faster than .NET Remoting
- %100 faster - %25 slower than .NET Enterprise Services (DCOM)
Those are impressive numbers. Unfortunately for the Remoting folks, there is an easy upgrade from ASMX but no upgrade from .NET Remoting.
Go WCF my friend!
Having worked on many rewrites, I often use The Roast was Too Big for the Pan analogy to explain why we need to understand why the code was written the way it was rather than parroting the system we are rewriting.
It's not necessarily safer to copy existing algorithms, because there are often interdependencies (read: kludges) between different steps of a long chain of calculations or transformations.
You need to make a conceptual model of the current system and then abstract the total effect of all the variables to really understand what is going on. This is a process called rationalization.
Take the time to really understand the algorithms and you will be much further along the road of both ending up with a working system and having a new system that is far more maintainable than the previous one.
I had forgotten my Sam Guckenheimer book Software Engineering with Microsoft Visual Studio Team System that has an excellent list of Qualities of Service (QoS) categories to consider for a project.
Fortunately someone has the list in a blog post. Thanks, Salvador Patuel, for including the list in this posting.
A co-worker of Sam's, Randy Miller, added a nice way to format QoS requirements: Context, Stimulus, Response. He also has a few more pointers. Please reference this post for the details.
Here's a quick post from the ALM folks at SRL Group that compares/contrasts TFS and ClearCase.
Key shortcomings of ClearCase:
- Integrated Interface like Team Explorer
- No PendingChanges window
- Administration difficult/No delegation
- Difficult to enlist in a project
I'd like to add the extra cost of ClearCase is a clear negative.
It doesn't list any shortcomings of TFS. I would suppose there are some.