Given: There are 2 solutions.

  1. MVC application
  2. A set of libraries with business logic

For debugging, I have to add the necessary projects to one solution. I just add the necessary projects with business logic from Solution 2 to my Solution 1 with my MVC application.

Problem: The problem is in the hint path and packages. The fact is that when you download Nuget Packages for a project, it puts them in the packages folder near the solution within which you did it.

When I add a project from solution 2 to solution 1, and then update / add some Nuget packages, they are downloaded to the packages folder for solution 1. While the project from solution 2 has a hint path of the type "/ packages. .. ". That is, he looks at his packages folder, 2nd, solyushna. Naturally you have to change the hint path so that they look at the packages folder not from 2 solution.

Why this is a problem: Because the check-in such hint path is impossible. And in the case when the csproj file has changed (for example, some files have been added), then you have to clean the csproj file. Write the correct hint path while leaving other changes, check-in-it, and then return the desired hint path.

Question: How to avoid these dances with the hint path and at the same time leave the opportunity to develop and build the project within the framework of different solutions?

Clarification: Each library with business logic lies in a nugget. And with the usual job decoding, I plug it in as a nugget. Without these dances with the addition of the project to the solyushnu. BUT. When a situation arises when I need to change this business logic and immediately update it within a specific application, then I have to take the source of this nuge and add it to the solution with my application. But my question is not about that at all.

My question is about the fact that this library with business logic, which I add to my solution for debug, has dependencies on other nuggets. And these nuggets need to be crossed in order to compile everything. But the problem is that the restaurant puts all the libraries in the package folder near the solution within which we do it.

A project with business logic, which I add to my solution, is physically stored elsewhere, and is part of another solution. And the hint path in csproj looks at the packages folder for its solution, and not for the one I add it to. Here is the problem.

I can not check these hint paths, which are changed to look at the packages folder of another solution. Because then the build will break on the build server.

Yes, I can keep an open solution which consists of a business logic to make a nuget-restaurant there. But I want to get rid of it and work within the same studio.

  • It makes sense to configure nuget so that the local package repository is outside the project directory. - VladD
  • @VladD I almost come to this. But this will mean that for each solyushna will need to fix nuget.config. If I don’t find an easier solution, I’ll have to do this :) - RoulanD
  • Well, this is only once. And you do not have so many of them? - VladD
  • @VladD And then I realized that this solution would not work either. Because the hint path should stay like "../ packages / ...". These are the requirements of the buildserver. And in the case of the allocation of a shared folder for all nuget, you will have to change all the hint path. - RoulanD
  • one
    Then request from the team dealing with the build server. This is their bug, let them fix it. Declare severity = high and let it work. - VladD

1 answer 1

We brought the common code into Nuget packages. We use TFS Online, where you can create your own package repository . This repository connects to both projects in Visual Studio.

All that was needed was learned from the Microsoft documentation .

Practical tips:

  1. For the Nuget, a separate repository was added to TFS Online.
  2. All Nuget's are kept in one solution, although this is not necessary. It’s just that she’s the team that works on us, and if they are different, they can be spread.
  3. nuget.exe keep nuget.exe right in the solution from point 2.

  4. We use a custom script on PowerShell to increase the version number of the package before building and publish. Looks like that:

     param($csproj, $version) if ($version -ne 'major' -and $version -ne 'minor' -and $version -ne 'revision') { Write-Host 'Usage: build-next-version <.csproj file> major|minor|revision' exit -1 } $csprojPath = Resolve-Path $csproj | Split-Path $assemblyInfo = Join-Path -Path $csprojPath -ChildPath "Properties/AssemblyInfo.cs" Write-Host "AssemblyInfo.cs: $assemblyInfo" $versionPattern = "AssemblyVersion\(""(\d+)\.(\d+)\.(\d+)\.0""\)" $assemblyInfoVersion = Select-String -Path $assemblyInfo -Pattern $versionPattern -List $matches = $assemblyInfoVersion.Matches if (-not $matches.Success) { Write-Host "Can't find [assembly: AssemblyVersion(""Mmr0"")]" exit -2 } $major = [Convert]::ToInt32($matches.Groups[1], 10) $minor = [Convert]::ToInt32($matches.Groups[2], 10) $revision = [Convert]::ToInt32($matches.Groups[3], 10) Write-Host "Detected version: $major.$minor.$revision" if ($version -eq 'revision') { $revision++; } elseif ($version -eq 'minor') { $revision = 0; $minor++; } elseif ($version -eq 'major') { $revision = 0; $minor = 0; $major++; } $newVersion = "$major.$minor.$revision" Write-Host "New version: $newVersion" (Get-Content $assemblyInfo) | % { $_ -replace "(Assembly(File)?Version)\(""([^""]+)""\)", "`$1(""$newVersion.0"")" } | Set-Content $assemblyInfo $nugetPath = $csproj -replace '\.csproj$', ".$newVersion.nupkg" Write-Host "NuGet packet: $nugetPath" $nuget = Split-Path -Parent $MyInvocation.MyCommand.Path | Join-Path -ChildPath NuGet\nuget.exe & 'C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe' $csproj /p:Configuration=Release & $nuget pack $csproj -Properties Configuration=Release -OutputDirectory $csprojPath & $nuget push $nugetPath -Source <Здесь вставить ULR хранилища, что-то вроде https://company.pkgs.visualstudio.com/_packaging/ProjectName/nuget/v3/index.json> -ApiKey VSTS
  • Thanks for the quick response. We also have our own Nuget repository. Publish to this repository occurs after the check-in, directly on the build server. But I do not quite understand how your approach will solve my problem. - RoulanD
  • @RoulanD, bring the code for shared projects into nuggets, then Visual Studio follows the correctness of references to other nuggets. Those horrors that you describe, just will not, every solution will follow their packages. In fact, your current approach has another problem: when refactoring in one of the solutions, you risk getting idle code in the other. You just don’t have to do this, but you have to put the general code into the nuggets, this is the right decision in this case. - Mark Shevchenko
  • I apparently did not quite correctly formulated the question. I wrote a clarification in the question header. This should clarify the situation. Thanks for your comments. - RoulanD
  • Yes, it became clearer. We are in this situation, sitting in two studios. - Mark Shevchenko