Migration to Nuget V3

Home

Source: own resources, Authors: Agnieszka and Michał Komorowscy

Sometime ago I wrote a post about My struggels with GitHub, Subtrees and Nuget and Joseph suggested me another solution of my problem in the comments i.e. to switch to Nuget V3. A few days ago I finally found time to give it a try. I started by reading this tutorial/post written by Oren Novotny. It's really a good source of knowledge so I'll not describe the whole process again. However, I encountered 3 problems that weren't described and I'll briefly write about them.

Project.json vs Project.config

A new Nuget uses project.json file instead of the old project.config so I started with adding this new file to all projects. Then I moved packages from the old files to the new ones. In the next step I reloaded all the projects just to be sure that VS will see changes. After that I built the solution to see if it works and it worked. Finally, I made a commit and pushed my changes. And here comes a problem. In a few minutes I got an e-mail from my Azure (hosted) build controller that a build has just failed.

§ Error: C:\a\_tasks\NuGetInstaller_333b11bd-d341-40d9-afcf-b32d5ce6f23b\0.2.24\node_modules\nuget-task-common\NuGet\3.3.0\NuGet.exe failed with return code: 1
§ Packages failed to install

The source of a problem was apparently a conflict between project.config and project.json so I just removed the former from the projects.

Naming problem

It is not everything. The next problem looked in the following way:

Failed to resolve conflicts for .NETFramework,Version=v4.6 (win).
Unable to satisfy conflicting requests for 'MVVMLight': project/MVVMLight (>= 1.0.0) (via project/MVVMLight 1.0.0)
Unable to satisfy conflicting requests for 'CommonServiceLocator': CommonServiceLocator (>= 1.3.0) (via project/MVVMLight 1.0.0)
Unable to satisfy conflicting requests for 'MvvmLight': MvvmLight (>= 5.1.1) (via project/MVVMLight 1.0.0)...

This time the fix was also easy. Nuget V3 doesn't like if the projects in the solution have exactly the same names as packages! In my solution I had MVVMLight project which is my playground for MVVMLight package. I renamed in to MVVMLightTest.

Last but not the least

After migration to Nuget V3 I had to deal with one more problem and again I didn't observe it locally but only when building on Azure (hosted) build controller. In the build log I found the following error:

The OutputPath property is not set for project 'LanguageTrainer.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x86'.

And it turned out that in some csproj files I had the following condition:

<Platform Condition=" '$(Platform)' == '' ">x86</Platform>

It says that if the platform is not specified for a given build then use x86. At the same time these csproj didn't contain configuration, including the problematic OutputPath, for x86. To fix a problem I simply changed x86 to AnyCPU.

Nuget in C++ rulez

Home

Source: own resources, Authors: Agnieszka and Michał Komorowscy

I haven't been programming in C++ for a very long time and I didn't expect that I would do it professionally in the foreseeable future. However, the life has different plans ;) Recently, I've joined an extremely interesting project in the area of the computer vision. In a while I'll try to write something about it.

Read more »

My struggels with GitHub, Subtrees and Nuget

Home

Source: own resources, Authors: Agnieszka and Michał Komorowscy

Some time ago I decided to publish my projects on GitHub. This decision had very positive repercussion because it mobilized me to do more refactoring and to clean my solutions. Additionally, I switched totally to management of external references via NuGet. Earlier, I had some binaries in a dedicated directory on my computer. It took me some time but it was worth doing it.

I also had to solve the following problem. I have a solution called Common. It is a collection of libraries, utilities, algorithms, helpers etc. that are used in my other projects. Before migration to GitHub, after a build, all Common binaries were copied to the well known location i.e. N:\bin Thanks to that all other projects could reference them from this location. It works. However, if someone wants to download my projects from GitHub, he or she will need to create a mapped drive N manually. I din't like it.

The next step was to switch from absolute references to binaries to relative references to projects. For example let's consider a library MK.Utilities and a project LanguageTrainer that uses it. Initially LanguageTrainer was referencing:

N:\bin\MK.Utilities.dll

After migration this reference was changed to:

..\..\Common\MK.Utilities\MK.Utilities.csproj

Much more better, isn't it? Still, it is not perfect. This relative path will work only if the folder with Common and LanguageTrainer solutions will be in the same place on the disk. Besides, in order to compile LanguageTrainer solution Common solution must be built first. What's more Common and LanguageTrainer are two separate repositories which have to be downloaded individually. My goal was to be able to download any repository/solution and then be able to compile it without any further steps.

I started reading about possible solutions and I found information about git submodules and git subtrees. There is so much about them in Internet so I will not repeat others. For example see this post. At the end I decided to use subtrees. Simplifying a subtree is a copy of some repository in the another one. Returning to my earlier example, by using subtrees I got a copy of Common repository/solution in LanguageTrainer repository/solution. Then I could change the reference to MK.Utilities as follows:

..\Common\MK.Utilities\MK.Utilities.csproj

Besides, I needed to add MK.Utilities project to LanguageTrainer.sln solution so that all projects could be build at the same time. Finally, my LanguageTrainer repository/solution looks in the following way. On left side you can see GitHub and on the right side Visual Studio:

If needed I can refresh a copy of Common repository/solution inside LanguageTrainer at any time. Why I used subtrees? Well, they work for me and are extreamly easy to create via Source Tree ;) By the way, I like git but I hate all this complex commands. Source Tree solves this problem and allows me to use git via friendly GUI. I strongly recommend it.

At the end I had to solve one more problem with Nuget. Let's return again to my example and let's assume that LanguageTrainer solution is located here:

C:\LanguageTrainer

In that case, by default, Nuget packages will be located here:

C:\LanguageTrainer\packages

However, we also have a subtree:

C:\LanguageTrainer\Common

And projects from a subtree expects that their packages will be here:

C:\LanguageTrainer\Common\packages

Of course they won't be there so Common projects will not compile. To overcome this problem I had to manually update csproj files and replace ..\packages with $(Solutiondir)packages. For example:

..\packages\structuremap.3.1.6.186\lib\net40\StructureMap.dll

Was changed as follows:

$(SolutionDir)packages\structuremap.3.1.6.186\lib\net40\StructureMap.dll

I hope that this post will help you in your struggles with GitHub, Subtrees and Nuget.