AddressAccessDeniedException on Windows 7

Trying to host the WCF service that has http end-point on Windows 7 can throw the AddressAccessDeniedException if the process does not have elevated permissions. Visual Studio can be started under the administrative privileges which will provide the required permission to start the service.

Namaskara,

Harsha

WcfSvcHost.exe on x64 machine

Visual Studio 2008/2010 ships with this tool that can help the in quick development and testing of the WCF service. It is a general purpose service host.

When you run this tool with the service built on the x64 machine with the platform target as Any CPU, we may be greeted with the application reporting in essence “WcfSvcHost encountered a critical error with System.BadImageFormatException exception”.

Re-compiling the code with the platform target as x64 (as highlighted below) will help resolve this issue.

Namaskara

Harsha

Free Visual Studio 2010 Training

I found this free online training for the VS 2010. Here is the link.

http://launchoffer.appdev.com/

I recommend you check this out…

Check it out. I have a yearly membership with them and the training are pretty good.

Namaskara,

Harsha

Disabling StyleCop for a single file

I am working on implementing an interface that is not finalized yet. Lot of things are in flux. But I want to continue to implement and make changes later on as things progress. The main problem for me right now is not the code but StyleCop. It keeps complaining about lack of documentation in my code. But I don’t want to write the documentation just yet as things can change too much and fix them all later. And, my build is failing. Not a pretty sight.

So in order to overcome this issue, I wanted to disable the StyleCop only for my CS file but leave it working for other files.

The easy way to do this is to put the following lines at the top of the file.

//------------------------------------------------------------------------------

// <auto-generated>

// This code was generated by a tool.

// </auto-generated>

//------------------------------------------------------------------------------

StyleCop does not complain anymore and my build is successful.

Cool, huh?

Later on I can go back and fix those documentation.

Namaskara,

Harsha

‘Like’ operator in Linq to Entities

Let’s say you have a query like the following

select * from product where lower(name) like 'computer%'

If you want to do the same thing in the Linq to Entities query, it is little tricky (at least for me :))

There is no operator by name 'like’ so we will have to make use of Contains, StartsWith, EndsWith keywords.

Here is goes…

public List<Product> GetProductsByName(string productName)
{
    var productQuery = context.Products.Where(p => p.Name.ToLower().StartsWith(productName));

    return productQuery.ToList();
}

Namaskara,

Harsha

Enable code coverage in Visual Studio 2010 Beta 2

I have started to code in Visual Studio 2010 BETA 2 and I have some unit tests that are already written up. I wanted to turn on the code coverage. It took a while to figure this out.

First thing I noticed when I double clicked on the Local.testsettings file is that the interface has changed and there are more options than I am used to.

After pocking around for sometime, I discovered that there was a Code coverage check box that I could check.

But even then I could not get the tests to capture the code coverage.

After more pocking :), I found that by double clicking on the Code coverage line in the “Data and Diagnostics” side tab, it opens up the Code Coverage Details window that lets you select the assemblies you want to include for code coverage.

Once I selected my assemblies, I was able to capture the code coverage matrix.

Namaskara,

Harsha

Goodbye Entity Framework 3.5 (aka 1.0)

With the availability of Visual Studio 2010 BETA 2 for developing production code, we can finally say Goodbye to Entity Framework 3.5. 

I was/am very new to the ORM arena. I spent like 2 months on and off to do some work with EF and to develop some applications and I have had some good and frustrating experiences with this. I wanted to put together some of these here.

Things I liked :)

• I was pretty amazed at how much Data access code is lessened by adopting this framework. Database tables are represented as entities and are regular C# classes and working with them was pretty easy.
• All the SQL commands are handled by the framework which could be good and bad depending upon the situation you are in. Since it takes care of generating the SQL statements for you for retrieving the data or persisting the data, this could aid in Rapid Application Development. But at the same time, you are giving away the control you had to develop the SQLs the way you wanted it.
• Framework along with the Visual Studio designer providers excellent view of the entities and their relations. You can add or update or remove the tables from the model (Entity Data Model) and the corresponding code behind is generated for you.
• Framework provides a good implementation of the Unit of work pattern for your application code. You can defer all the database operations until the ObjectContext SaveChanges() is called.

Things I did not like :(

In spite of all these advantages, I did suffer from some issues in adopting this effectively in my application development.

• Lately, I have become a big fan of unit testing and TDD. Entity Framework 3.5 does not help with effective unit testing by using mocking. So, this was quite frustrating to deal with. TypeMock allows you to mock classes without interfaces, but it is a commercial product and is little pricy for me.
• There is no support for using POCO classes for entity development. So extending the framework generated classes is not very elegant. All the classes generated by framework are decorated with partial class keyword, this provides an opportunity to add our own code in your code files. But this approach becomes very ugly very soon if you are extending lot of entities.

Most frustrating factor of all is that I could not settle down with one good code architecture. I considered various levels of separation between the business code and the entity framework code and each one showed its own ugly face.

• The first pattern was Business and data access are complete separated. DAL layer would completely encapsulate the framework. Data access components exposed interfaces that business layer can call.
• Business Layer had a set of entities to manage the business needs.
• Data access layers had entities generated by the framework
• The data transfer between these layers were happening using DTOs which looked like entities themselves.
• I had so much similar looking code among these three components that I was spending more time managing them. (My business entities looks like my data access entities, unfortunately)
• Managing transactions was an issue too as the transactions was maintained by the DAL layer. I did not wanted to use TransactionScope as it will affect my application performance.
• The second pattern was to mix the business and data access and use the framework generated entities as my business entities also. Though this looked like a good approach in the beginning, I soon realized that the boundary between the business and data access had completely vanished. If I had to replace the entity framework in future (oops), I have to redo everything and it violated the golden rule of separation of concerns 
• The third approach was to have minimal framework code in the business layer. ObjectContext creation, handling transactions (using EntityConnection) can be handled within the Business layer very easily and had the potential to become very satisfactory code architecture to use. But the above mentioned limitations (unit testability, extending entities) will not give you sense of peace.

These kinds of concerns have already made it to the list on the Vote of No Confidence. Take a look at this list.

We now have a new version of Entity Framework in .Net 4.0 which is going to address my concerns and I am now trying to give it a spin and I like whatever I have seen so far. It has POCO support and was developed with testability in mind. I will write up more on the new version later on.

With the availability of this version, I can safely say goodbye to Entity Framework 3.5 and say hello to 4.0.

Here are the great blogs that have helped me to get answers I needed on all of these

http://devblog.petrellyn.com/

http://blogs.msdn.com/adonet/

http://blogs.msdn.com/diego/

Namaskara,

Harsha