1. Windows Identity Foundation (WIF)

    I’m really excited by the Windows Identity Foundation (WIF). And now it’s a part of .NET Framework, so it can be used in any .NET application. The team did great work by providing us awesome “plumbing” code, so now we can build truly separated systems very easily. Also WIF provides 100% backward capability to the old (IIdentity/IPrincipal) approach! Claims allow us to describe identity using key/value pairs. So we can deal with claims such as name, email, etc. WIF allows to make Claims Transformation. So the application will have to deal only with domain specific claims, and it won’t have dependency on the underlain authorization mechanism. For example we can transform  AD Groups into domain specific roles. Sure we can also make any custom Claims Validation as well. Claims-based Authorization is a piece of cake. Again you deal with domain specific terms. Here’s simple example:

    [ClaimsPrincipalPermission(SecurityAction.Demand, Operation = "Add", Resource = "Customer")]
    public void AddCustomer() { ... }
    As you can see your business logic says - this is “Add” operation and “Customer” is resource. And we have a single method to implement authorization logic:
    public override bool CheckAccess(AuthorizationContext context)
    	// please note that we deal with arrays here, so we can use more complex expressions in describing our business logic requirements.
    	var resource = context.Resource.First().Value;
    	var action = context.Action.First().Value;
    	if (action == "Add" && resource == "Customer")
    		return context.Principal.HasClaim("http://myclaims/someclaim");
    	return false;
    As you can see on above example we could move authorization logic to the separate assembly or even Web Service. It needs to mention that WIF supports Claims caching. For example you can use AppFabric cache to store transformed claims instead of make transformations for each request. And it support SAML tokens to seamless third party authentication. So you can use AD FS  or even Windows Azure. …

  2. Visual Studio 2012 Page Inspector

    For years I used FireBug to inspect HTML, CSS. But Visual Studio team did great work and now we got even better functionality right inside our favorite IDE. What’s so awesome about it? You can “Inspect” any element on you HTML or CSS and Page Inspector will show you a line in source code that produced that element! 4 minutes introduction video could be found here http://www.asp.net/vnext/overview/videos/visual-studio-2012-page-inspector. (thanks to Scott Hanselman) …

  3. Git on windows

    Finally got some time to watch Phil Haack’s talk Git and GitHub for Developers on Windows. It was really interesting. GitHub for Windows has really nice clean UI. Fun thing is that recently we used the same model to deliver our software as GitHub folks did – use ClickOnce as a deployment technique. Although we went a little further with it. Our installer doesn’t show any standard ClickOnce windows, it just uses API to streamline installation process. Also we build personal installer for each user who gets invitation or license, cause each copy could be installed just once. …

  4. NuGet without committing packages to source control

    Several days ago switched to new approaching of working with NuGet by enabling NuGet Package Restore featrure. From now packages aren’t being stored into source control. Instead NuGet download missing packages during build. So far so good. …

  5. Entity Framework (EF), UnitOfWork & Repository patterns

    There are some debates on the network about if we need to add abstraction layer on the top of Entity Framework. Or it’s redundant. Sure, I have my own opinion as well Smile Entity Framework (EF) object context provides us ability to make whatever we want with any table in database. So if our business logic uses EF directly our data access code will be spread through it.  Me personally like Persistence Ignorance pattern so business logic shouldn’t be aware of the data layer details. Furthermore I like then each repository contains some related methods. Usually it’s something like UserRepository, ChangeRepository, PostRepository, etc. It helps to structure code since in this case we don’t have huge repositories. EF implements UnitOfWork pattern and that’s amazing. So that we did in our last project is used EF object context as UnitOfWork and passed it to our Repositories. (it was wrapped into IUnitOfWork, probably I’ll post some technical details later) We used Code First approach and all our POCOs were located in the Model. So business logic worked with Model not with data. That’s worked like a charm. We got clean data layer and business logic. It’s very easy to unit test and maintain. …

  6. Distributed version control (DVCS)

    For a long while I was interested to try out some DVCS. The problems caused me to not do that was really simple – which one to choose Mercurial or git? I read some technical articles and came to a conclusion that Mercurial has better merge capabilities. Unfortunately I don’t have links to these articles (I read them several months ago) But what I like about git is that it has a huge community and that’s why there are many neat tools for it. For example there is a two-way bridge between TFS and Git. Today I came over Mercurial, Subversion, and Wesley Snipes article and Eric Sink says there:

    But if I were choosing a DVCS as a regular user, I would choose Mercurial. I've used it some, and found it to be incredibly pleasant.  It seems like the DVCS that got everything just about right.
    But in my particular case of .NET development using VS 2010… Mercurial isn’t seem that simple to use. Here’s some information on Real-world use of Mercurial with a Team Foundation Server. On the other hand there is a plug-in that integrates git with Visual Studio and a two-way bridge between TFS and Git. So it seems git wins a competition for me… at least for now. …

  7. primaryGroupToken via C# from Active Directory (AD)

    I needed to change Primary Group of the Active Directory user programmatically (via C#). I found a good example in PowerShell. But it wasn’t obvious for me on how to convert the following code fragment into C#:

    $NewGroup = [ADSI]"LDAP://CN=Domain Guests,CN=Users,$DomainNC"
    $NewGroup.GetInfoEx(@("primaryGroupToken"), 0)
    $NewGroupToken = $NewGroup.Get("primaryGroupToken")
    So here is it, just in case it isn’t obvious for you as well ;)
    group.Invoke("GetInfoEx", new object[] { new object[] { "primaryGroupToken" }, 0 });
    object primaryGroupToken = group.Invoke("Get", new object[] { "primaryGroupToken" });

  8. Command Query Responsibility Segregation (CQRS) pattern

    I’ve just read excellent introduction to the Command Query Responsibility Segregation (CQRS) pattern. And you know, it seems really worthy to have in a toolbox.
    Actually just to be ready to use it I’ll need to research many related patterns such as Reporting Database, Event Sourcing, etc..
    So check it yourself - read this great CQRS introduction to see how many useful patterns and practices those are related to CQRS you don’t know yet ;) …

  9. MSpec and TFS Build Service (MSMSpec)

    If you are going to use MSpec in your next .NET project you could face the following issues:

    1. Visual Studio won’t be able to execute MSpec specifications. (MSpec has it’s own test engine)
    2. TFS Build Service is able to run only MSTest.
    I found several articles on that problem in search engine. The best solution I found was MSMSpec. I’m very appreciate the work HeartattacK had done since it really helped me! MSMSpec is a T4 template which creates MSTests based on your MSpec classes. So it provides us ability to run MSpec specs in Visual Studio and in TFS Build Service, calculate Code Coverage and Test Impact using MS tools. Here’s my approach to get it working:
    1. I added MSMSpec.tt to the solution items. And added its as a link to each MSpec project.
    2. I made TestExecutionHelper class internal. It was public initially, so if one MSpec project is referencing another, public TestExecutionHelper will result in a conflict. (since both assemblies are declaring the same class). MSMSpec author suggests another workaround but it doesn’t fit my need since I use shared MSMSpec.tt.
    3. I added 108 to the suppress warnings list in all MSpec projects. (to suppress “_Setup hides inherited member. Use the new keyword if hiding was intended” warning)
    4. Finally I fixed Cleanups execution order (Parent class Cleanup should be called after Child class Cleanup):
    1. //var cleanupInfos = FilterByType<Cleanup>(fieldInfos);
    2. var cleanupInfos = FilterByType<Cleanup>(fieldInfos).Reverse();
    Thant’s it. Hope this helps someone! …

  10. Team City: Windows Authentication

    There is detailed article on how to configure different authentication modes in Team City. But it lacks some information… Let consider the following example:

    1. You setup Team City
    2. Configured Project in it
    3. All went fine and now you need to configure user access
    4. So you switched Team City to Windows Authentication
    5. Now you can login with you Domain credentials, but you can’t give administrator rights to any user since you don’t have administrator yet
    So I found the following workaround:
    1. Login using Default Authentication Mode as Administrator in the Browser #1
    2. Switch Authentication Mode to Windows Authentication
    3. Login in as a Windows Domain User in the Browser #2
    4. In the Browser #1 open Users and Groups
    5. You will see newly created user account for Windows Domain User logged in using Browser #2
    6. You can select this account and give it administrative rights