Using Overridden members with Partial Mocks for abstract Types

For a serious unit testing mocking framework is a required piece. It allows creating mocks for dependencies we don't want to instantiate in our code. We discussed about partial mocks long time ago [refer post]. They are specially useful for testing abstract types. Actually they provide a proxy implementation for the virtual / abstract members.

In this post we are going to discuss a special case when we have overridden some members of a parent type. We might not have overridden the other members or we just are good with the default null proxy implementation. Generally the mocking framework would just provide proxy implementation for all virtual / abstract members. How can we make sure that it uses the implementation in our type if we have provided so.

For our demo project, we are using nunit with Moq. Let's create a test project, and add the following nuget packages.



Here we have introduced BaseClass with a public member [Calculate] and two abstract members [CalculateCore and SomeOtherMethod]. It is inherited from another type ChildClass, which provides an implementation of CalculateCore only.


Now let us try to add unit tests for testing the functionality for this type. Here we have added a methods to check the result of Calculate method. Since we have added a definition of CalculateCore member, it should be adding the two parameters and just returns the result.


When we run this test, we get failure. If we look at the result, it doesn't actually make a lot of sense. Actually it is not even using the CalculateCore implementation from ChildClass.



But can we actually tell mocking framework to avoid providing implementation of overridden members. Actually Moq supports this by providing CallBase member for Mock. Here we have another implementation of the same ChildClass. The only difference is that mock has this member set. Now it should use the overridden member, CalculateCore, and test should pass.


And test passes now, Zindabad!!!

Resharper Extension - Auto Nuget Installation

In this post we are going to discuss a new Resharper extension. We are going to discuss why we need it and how it makes our lives easier as developers. The extension is called Nuget Support for Resharper. The package works like another feature of resharper where it suggests assembly references for types used in a project based on the other projects in a solution. The extension extends support for suggesting nuget package reference instead of an assembly reference if the assembly comes from a package. You can install the package using Resharper 8 EAP Extension Manager.



We discussed about Extension Manager feature in Resharper 8 EAP before. You can refresh your knowledge here.

Creating Package
Let's create a sample class library project Core.Interfaces. The project is targeting to framework version 4.5. You can skip this part if you already have a package to reference.



Let's add some interfaces to the project. This is a library for providing necessary API for order processing. Here we are providing an interface IOrder as a contract for an order. We are also adding an interface for Order Factory.


Let's first create the nuspec file for the project. We use Nuget command line tool to create the specification file. We need to provide the path of command line tool so that it could create nuspec for the *.csproj file in the current folder. To save the trouble each time, you can provide the tool's path in the %PATH% environment variable.



The specification is created with a few tokens. Let's cleanup the file keeping the required tokens as follows:


The tokens are populated with the assembly attributes as specified in AssemblyInfo.cs in the project if this nuspec is used to create the project. You can use the following mapping from nuget.org specification.



For our project, I have updated the contents of AssemblyInfo.cs as follows:


Now let's update the post-build event for the project to create a nuget package. Since we have nuspec file in the same directory as the csproj file, nuget tool should use nuspec file definition to create the package. It should then use the assembly for token replacement generating the resulting package. Here we are creating the package in a specific output directory. For the local development, we can use the path as a local repository for the package. Now updating the package in any project would use the latest source package.



Now whenever we build the project, the nuget package is created in the output directory. The package for Core.Interfaces is created as follows:



Adding Local Package Repository
Now let's make sure that the package is used from the local storage. We can also uncheck nuget.org path to make sure that packages from only this repository are being used. You might need to clear up local package cache for extra safety. Let's add the local package path to the nuget package manager setting as follows:



Using Package from Local Repository
Now let us add another class library project Core.OrderProcessing. We install the nuget package previously created to this project. Just make sure that Local Repository is selected before you install the package.



Let's provide the definition of the interfaces introduced in Core.Interfaces project as follows:


Now let's add another project to write unit tests for our library. Let's use xUnit for these tests.We discussed about this extension in our Resharper 8 features' discussion here.



Let's add the following tests for testing OrderFactory:


Since the types are returning interface types, we need to reference Core.Interfaces library. Here Resharper is really helpful for helping us what library references we are missing. It goes one step further by making it easier. It provides the support in action bar to add the required assembly, which is quite amazing.



Selecting the above option add the required assembly reference in the project. This is a well known resharper's feature. Although this is great for other assemblies but this is not perfect for the assemblies coming from a nuget package, which is exactly the case here. The assembly is referenced from packages folder.



Extension to Install the Source Package
In order to help us with the above scenario, we can use Nuget Support for Resharper. This is a resharper extension which can be installed using Resharper's Extension Manager. If we install this, then selecting the same extension would not directly reference the assembly from packages folder. It would install the source package instead. Installing the source package would automatically install the other dependencies for this package, which is even better.



It must be remembered that the extension doesn't add an extra item to the action bar. It just uses the option to add the assembly reference but it installs the source package, and hence, all of it dependencies. Since the type was sourced from Core.Interfaces, the same package is installed. An entry is added to project's packages.config file. The package installs a reference to the required assembly. Additionally all the required namespaces are added to the code.



Zindabad!!!

Possible Improvements
There is still room for improvement for the extension. Although it does a very good job for installing the source package in the scenario where the types are sourced from a package but it seems to only work in the scenario where there is an explicit usage of types. In the case of implicit scenario where the assembly should be referenced because of cases like return type of a method used. In those cases, still the resharper suggests to add the required assembly and the assembly is directly referenced from the packages folder. Let's update the code for our test as follow.


Here we are not explicitly specifying the type but since GetOrder returns an IOrder, it requires an assembly reference of Core.Interfaces.



Let's see the reduced options in the action bar. There is an option to add the required assembly reference. Let's use that.



Selecting the above does add the required assembly reference (resharper's feature) from packages folder. It doesn't install the required package. I think the extension can also listen for this scenario and install the source package instead.



Download

Project Retargeting Framework Version and Nuget Package Installation

Earlier we discussed an issue with portable class library references when a project is retargeted to a different framework version. The issue was discussed here. It was subsequently reported to Microsoft on Connect. The issue was that portable class libraries have restrictions when we add their reference to a target project. But if a project's target framework is updated after we have added a portable class library reference then we don't know what references of PCLs do we need to update. Later it was improved a little to provide visual cue for invalid PCL references.

Let's use the same NugetPackageRestoreEx console application created in the previous post. The project has Ninject nuget package referenced.



When the package was installed to the project, the project was targeting .net framework 4.5, hence all the required references were also targeting the same framework version. The world is really a happy place.


Now let us retarget the project to .net framework 3.5 from the property page of the project.



As we retarget the project, the nuget package references might become invalid. Nuget 2.7 added a new feature to help in this case. As soon as we retarget the project, there is a build error generated and the Errors List window is displayed with the details about the possible error.



The update has also added a new attribute to the packages.config schema. This is also notified in packages.config stating that you would require a re-installation of this package as per the updated targeted framework version of the project.



The error is transformed into a warning as we rebuild the project. Since the developer has been notified with the possible risk, it should be fine.



Download

Automatic Package Restore in Nuget 2.7

Microsoft released the latest Nuget Package Manager late last month with a few bells and whistles. This is version 2.7 of the tool.



Now we have discussed about Nuget in the past a few times.

• Using Nuget Packages in an Enterprise Software:
  Including discusion about the automatic / manual package restore, creating packages and visualizing their dependencies in a solution.


• Hosting Nuget Feed:
  How we can host nuget package from intra-organization consumption.

You can find the discussion about why we don't want to check-in packages folder in the source repository in the first post. This calls for automatic package restoration as the developers build their project after getting it from source repository. This post is all about the enhancements in automatic package restoration in Nuget 2.7. Let us first try to update the Visual Studio Nuget Package Manager extension. Here we are updating it in Visual Studio 2012 Ultimate.



After updating the extension, we can notice that the package manager settings for package restoration is updated. We now have the following view [Tools -> Library Package Manager -> Package Manager Settings]. The available options are selected by default.



It seems a little confusing that an extra sub-option is provided for package restoration during build of the project. We should also see what it results if we have the first option selected while not opting for the second one. The package restore settings used to be as follows in the earlier versions of Nuget Package Manager. It just has one option to allow restoring the package.



Let us create a sample Console application NugetPackageRestoreEx. We install a reference nuget package Microsoft.Diagnostics.Tracing.EventSource. It's a pre-released version, hence -pre switch. You might also be noticing the package source being nuget.org, this is another enhancement in the new version of the extension. I think it is better than what it was called before i.e. official package source.



This should create a packages folder in the project directory. Let us remove the folder. This would be a real test if we are able to restore the package automatically during build.



In the earlier versions, we needed to enable package restore for the solution which was fulfilled by incorporating nuget.exe in the solution with adding build target to install packages by nuget.exe using packages.config for each project. In the current release, this should automatically work without setting anything for the solution or project. As the package is being restored, we see the following information message being displayed clearly specifying the packages being downloaded. We notice that as we build the project again, the packages folder was restored successfully.



Since this is now automatic, it doesn't really make sense to still have Enable Package Restore option for the solution. It seems that the option is going to go away in near future. Selecting the option would add a .nuget solution folder.



Package Restore on a Build Server
Now that we have seen the restoration of packages in Visual Studio through Nuget Package Manager extension updates. What about the build server as you wouldn't expect build server to be running Visual Studio. For this, there are updates in nuget.exe to restore packages in a solution and its projects. If there is only one solution in a folder, then we don't need to explicitly specify the name of the solution. But first we need to download the nuget.exe command line utility.



We simply need to run the following command before we run MSBuild targets. This would ensure that all the packages as specified in the solution's or containing projects' packages.config have been downloaded. As a group policy, we can copy the nuget.exe to a universal path on build machines.

nuget.exe restore

The above command should download all the nuget packages as described. It's a different package that I used later on. But you should be getting the idea.



In order to make it more easier for developers, from the release notes it seems that the nuget team has been working with Continuous Integration servers to automatically use nuget restore command before build task. This would make sure that we don't require any changes whatsoever in our solutions or projects. The CI servers mentioned in the release notes are TeamCity, TFS and Appharbor. It also includes Windows Azure websites so that the packages are pushed and restored before the website is built.

Download

dotPeek peeks Nuget packages now!

JetBrains has announced today a new plugin for dotPeek. This is to provide support for peeking into nuget packages without downloading them. This allows us to source packages from the chosen nuget repository. We can search for appropriate package and open them in Assembly Explorer.



It is also possible to peek all nuget packages as referenced in a packages.config file.



As we discussed in our previous post that assembly explorer has already been added to Resharper 8 EAP, there might be future support of the same feature in Resharper 8. After installation, the package should be available in installed plugins list. This can be enabled or disabled by using the options here:



You don't need to download the dotPeek 1.1 EAP as the plugin is also supported for RTM version of the tool. You can find further details about the plugin along with download instruction on JetBrain's blog here:

http://blogs.jetbrains.com/dotnet/2013/05/peeking-into-nuget-packages-with-dotpeek/

Nuget 2.5 Released This Week!

Microsoft finally released Nuget 2.5 this week (Apr 25, 2013). It is a very big release with 160 work items. In February, we discussed about some of the challenges introducing Nugets in an enterprise world. They included using nuget packages in an enterprise world and hosting internal nuget feeds. The release is a good news for native developers as the realase added support for C \ C++ projects. You can see the announcement on CoApp site where they announced CoApp power shell tools for Nuget 2.5. The tool was also released yesterday.



A new version of Nuget Package Explorer has also been released yesterday. The click once download is available here:



The new version of the explorer is released to be compatible with this release of Nuget [2.5]. There are still some features which are still not supported in the explorer including .net framework version specific references.



We can easily divide the released features as the improvements for packages clients and authors. There are various improvements for packages clients. The most obvious improvement which you would notice is the ability to update all packages which are already installed. Please notice the Update All button in the dialog to manage nuget packages.



As a package author, we can now enforce Nuget version on client machines before they install your package. This would make sure that clients have enough support for the features our packages are based on. Obviously this feature would be usable by the nuget clients 2.5 and above as the earlier clients don't know how to handle this metadata attribute. The attribute can be added as follows:

Installing Nuget package with requirement for higher version of Nuget would result in an error. In Visual Studio, it would show you the option to upgrade Nuget version. This would open the dialog for extension and updates in Visual Studio listing the available updates.



If you have earlier version of Nuget supporting previous versions of Nuspec, the package is shown in Manage Nuget Package dialog as follows:



The similar error message is available when package list is requested using Package Manager console (Get-Package -ListAvailable).



We cannot install such a package using Manage Nuget Pacakge Dialog.Installing such a package using Package Manager Console would also result in the following error message:



In the previous versions of Nuget, we could limit the assemblies to be added to target project's assembly references. The filtered list must be part of the assemblies in the lib folder or one of its framework specific sub-folder. Let's assume we had these two libraries in v4.5 folder for our package.



By default, if a client is adding this package, both of these assemblies would be referenced by the client project. If we need to reference only a filtered set of assemblies from the source set we can include the list in the nugetspec for the package. This would still copy all the assemblies to the packages folder.

This should allow you to include the assemblies that are dependent on some other assemblies where you don't want the types from these assemblies to be directly used by the client code.



Nuget 2.5 allows to define this filter based on the client's target project. This has been provided by including framework specific groups in the nuspec. We can also include a framework independent group as a fallback mechanism when our package is referenced by an unidentified framework version.


File Overwrite Option for Package Installation
A new option has been added for package installation to give the user an option to overwrite an existing file or keep the copy of the content already present. Please notice FileConflictAction with Install-Pacakge command. Here we are installing MyPackage while selecting to overwrite contents already present. The options are Overwrite and Ignore.



Installing package with Manage Nuget Packages dialog would give you an option to overwrite or ignore the content.

Import for MSBuild targets and props files
A new build folder is now supported at the root level in a package. The folder supports framework specific sub-folders. The build folder contains targets and props files. When a package is added to a target project, it would add <Import> in project file.



Please notice how these <Import> elements are added to the project definition. The element for build is added to the top of the project file.



The element for props file is added to the top of project definition as follows:



You can find further details about it from the release documentation available here:

http://docs.nuget.org/docs/release-notes/nuget-2.5