26/12/2016

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.

1 comments:

Anonymous said...

Your post is on morning brew - http://blog.cwa.me.uk/2016/12/29/the-morning-brew-2252/

Post a Comment