Nuget Dependency Management - what are my options? - nuget

I have started at a new company recently and was tasked to resolve dependency management issues.
Tools:
Visual Studio Enterprise 2015
Nuget 3.x
Team Foundation Server 2012 (won't be upgrading for at least six months)
MS SQL Server 2008
Current Dependency Management solution is to use Project References (it's quite the web of confusion)
.NET FrameWork 4.0 (they won't be upgrading anytime soon - several dozen products all written in 4.0 or earlier)
I have tried to get nuget packages and dependencies to work with VS 2015 and the tools above. The problem I run into is a common one: csproj hintpaths written to the csproj file. If I can't get flexible versions for these dependencies life is unpleasant.
I am looking for something more flexible like Project.JSON where we can use Transitive Restore.
My first impression is I am stuck with classic csproj and hintpath hell.
Thoughts?

With Nuget 3 you can use project.json. That may be the best bet here.
Thanks everyone! :D

Related

An exotic problem happens when the entity framework gets installed by NuGet

I just simply want to install Entity-Framework 6.3.0, but an exotic exception is thrown by NuGet package manager. it says :
Install-Package : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003
format.
I haven't seen such an exception before, and don't have any idea what it exactly means.
I use
Visual studio 2013
.Net Framework 4.5
I have already tried to resolve the issue. Nonetheless, it didn't work out. Actually, I tried to follow the exception's instruction and add the mentioned attribute into the project tag. It was not useful at all!
Let me tell you that I have actually created a repository on GitHub, cloned the repository, and finally created this project inside it. I don't know if this process is relevant to the problem, though I think you should know that.
I will be glad if you guys tell me what the problem is and how I can resolve it. Thanks.
EF 6.3 requires MSBuild version 15 which ships with Visual Studio 2017. That appears to be your issue. You may be stuck on version 6.2 until you upgrade.
I simply downgraded Entity Framework to the 6.2.0 and the problem was solved! Although NuGet introduces 6.3.0 as a stable version of the EF, it seems that the version has a huge problem with either VS2013 or .Net 4.5

Nugets packages from .net Standard 2.0 projects not showing in NuGet packages tab in TeamCity

We have a .net solution that contains .net standard 2.0 projects and .net framework projects.
On each build with TeamCity we have a step with NuGet Installer to restore the nuget packages for solution (nuget version 4.3.0). The step works fine, it restores the nuget packages but on Nuget Packages tab at Used Packages section we see only the nugets from .net framework projects.
Only the .net framework projects have packages.config file, the .net standard 2.0 ones doesn't have this files because nuget package manager uses PackageReference by default (as stated here https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files) so the nugets used are included in .csproj files.
What can be done in order for nuget packages for .net standard 2.0 projects show up on on Nuget Packages tab at Used Packages section ?
Thank you,
Adriana
Seems is a known issue of TeamCity, and if we need it fixed we should vote for it here: https://youtrack.jetbrains.com/issue/TW-52327
If anyone else has a workaround till is fixed please post it :)

Is there a way to automatically deploy nuget packages in Visual Studio 2017?

I'd like to know if there is a way to automatically deploy NuGet package.
I tried many extensions but not working for VS 2017.
I do know that there is a packager as new VS 2017 feature. But there is no package tab in my project (.NET Library) properties.
If you want the integrated package management for .NET Framework Libraries (not .NET Standard or .NET Core), you can create a .NET Standard Library and edit the csproj file by replacing
<TargetFramework>netstandard1.4</TargetFramework>
with
<TargetFramework>net461</TargetFramework>
There is no built-in template yet for this library type and some designers (win forms, xaml, ..) will not be available but this unlocks all integrated packaging features.

Nuget Package supporting multiple versions of their dependency

I'm looking for some experience or thoughts on the following problem.
I have a Nuget Package (EntityFrameworkExtras 1.2.0) thats hosted on the main Nuget Feed.
This package has a dependency on EntityFramework. Everything was hunky dorey until EntityFramework 6 was released.
A change in the EntityFramework code means that my package no longer works with EntityFramework 6 and onwards.
I'm trying to consider how best to deal with this problem, i foresee two options:
1) Maintain 2 versions of the Package
So, i would have one version of the package that is compiled with EntityFramework 5.0.0 and the .nuspec would
dictate that it is dependant on EntityFramework [0.0.0 - 5.0.0]
I would introduce a new package called EntityFrameworkExtras (ef6). This package would be compiled in EntityFramework 6.0.0
and the .nuspec would dictate that it is dependant on EntityFramework [6.0.0 >= *]
2) Have a new version of the current package that would support EntityFramework 6.0
so the currently version would support EntityFramework 5.0.0 and less
and i would add a new version of the package (version 2.0.0) that would depend on EntityFramework 6.0.0 [6.0.0 >= *]
I went for option 1) in the end. I believe this is an easier option for the user of the packages because its clear what each of the package's dependencies are.
I also believe its easier to use the nuget commands when working with different packages, rather then attempting to be aware that different versions of one package have different dependency versions.
Also from a development perspective it cleaner and easier to develop and fix bugs on the different packages. Finally, it would make a continuous integration environment easier to implement, because each package would be consider a different project.

NuGet, MvvmLight toolkit, is NuGet necessary for all developers?

I have an application for which I've installed NuGet packages for the Mvvm-Light Toolkit, and I've completed and checked in these changes to TFS. All of the package folders exist in TFS, and the .csproj file references to the GalaSoft libraries are correct, i.e.:
<Reference Include="GalaSoft.MvvmLight.WPF4">
<HintPath>..\..\packages\MvvmLightLibs.4.3.31.1\lib\net40\GalaSoft.MvvmLight.WPF4.dll</HintPath>
</Reference>
However when other developers do a Get Latest, their references to those libraries are not found:
I don't believe they have used NuGet, but does this matter? Does each developer have to go through the same NuGet installation of Mvvm-Light to avoid this?
On TFS you need to check-in the whole solution and not just the project because if you check-in just the project then the dlls will not be checked-in.
You can also get Visual Studio Team Foundation Server 2012 Power Tools http://visualstudiogallery.msdn.microsoft.com/b1ef7eb2-e084-4cb8-9bc7-06c3bad9148f this will allow you to see outside of Visual Studio in your folders if you have checked in the dll or not.
Good luck!