Support mulitple projects in one folder in v3 #1102

Closed
nigel-sampson opened this Issue Aug 3, 2015 · 25 comments

Projects

None yet

10 participants

@nigel-sampson

Projects such as Caliburn.Micro that support a number of different platforms (soon to be eleven with Xamarin and Windows 10) structure the solution in a way that the code for the assemblies is located in a single folder.

An example of this is the Caliburn.Micro.Platform assemblies.

Dealing with project specific nuget dependencies in v2 was dealt with by prefixing packages.config with the project name.

This approach isn't supported in v3 and project.json.

From some discussions it appears the recommended approach is to restructure the solution to use a shared project and separate project heads for the platforms enabling each project.json to be in it's own folder.

@Nezz
Nezz commented Aug 4, 2015

We have the same issue at MonoGame. NuGet 3 doesn't even care if the project.json is included in the project. If it finds it in the folder then it tries to restore packages.

    <None Include="project.json" />
@Nezz Nezz referenced this issue in MonoGame/MonoGame Aug 4, 2015
Merged

Win10 RTM support #4031

@tomspilman

We have the same issue at MonoGame.

I'm one of the core maintainers of MonoGame. We have no plans to re-arrange our project to work around this oversight in the implementation of NuGet 3.

Instead our plan is to stick to VS2013 until this issue is resolved.

@nigel-sampson

So I've done a trial run in refactoring Caliburn.Micro solution to using shared projects instead of the single folder approach.

In short it's not workable due to the all or nothing approach of shared projects which makes sharing files with a subset of projects without a massive amount of things like #if NET && WINRT && !XAMARIN at the top of dozens of files.

Would really love to see this solution resolved as we're going to have to with another approach to solving this.

@nigel-sampson nigel-sampson referenced this issue in Caliburn-Micro/Caliburn.Micro Aug 5, 2015
Closed

Supported Visual Studio versions and Platforms #209

@yishaigalatzer

nuget (particularly the nuget command line) runs outside of msbuild, and does try to understand if project.json is part of the project.

We do need to look into this, but I'm not sure I follow the problems. The suggestion is to move the csproj files to another folder and put the project.json next to it, and then have the projects link in the files. I don't see where the #if comes into play.

@pilchie

@yishaigalatzer

@tomspilman I understand the frustration this caused, and we are going to see how we can come up with a solution. The sticking point is that we can't just release a new nuget extension to support it, and we need a coordinated release with @pilchie 's team. I'll work with him offline on this. It just means the fix is less immediate.

is your plan not to build UWP specific packages? Which I think is just fine if the packages work for UWP. I'm not quite understanding the issue (like I asked above), because it seems like directory a re-arrangement problem which shouldn't be a big hassle. What am I missing here?

@tomspilman

Hi @yishaigalatzer.

It just means the fix is less immediate.

That is ok... we can wait until this is fixed to fully switch to VS2015.

is your plan not to build UWP specific packages?

No... we plan to build UWP packages for UWP platforms using VS2015. We just have to keep VS2013 installed and use it for all our other platforms.

it seems like directory a re-arrangement problem which shouldn't be a big hassle. What am I missing here?

The issue is everything else we have to fix... our project generator, build instructions, build scripts, installer scripts, etc. for 8 or 9 platforms.

Beyond that it is a bad directory structure. There is no good reason to hide projects in folders like this. It is only a hack to work around this NuGet issue... and IMO it is NuGet that needs to be fixed.... not our project.

@yishaigalatzer

No one is arguing that NuGet should not add this, it is just a release schedule thing. Its not just NuGet, its NuGet + C# project system picking up renamed lock files, and PCL updating the correct project.json. These kind of integrations are not happening overnight.

I also don't necessarily agree that separating the projects is a hack, multiple csproj files in a single folder is kind of a similar hack. But this is just a taste thing, and obviously your choice, not mine.

There is no finger pointing or who is to blame, its all about supporting our customers. As long as you have a solution I'm happy, and we will do our best to come out with a solution as soon as possible.

@yishaigalatzer

Moving tentatively to the 3.1.2 milestone, assuming the visual studio tools can support it in a similar timeframe or through an msbuild task.

@yishaigalatzer yishaigalatzer modified the milestone: 3.2.0-Beta, 3.1.2 Aug 6, 2015
@nigel-sampson

This may be a misunderstanding about what everyone is saying when referring to "shared projects". I took this as many using the "Shared project" type in Visual Studio shproj.

The problem (at least for me) is that recommendation to move to using a Shared project in one folder and project heads in other folders instead of having all the source / projects in one folder isn't workable in the long term.

This is because there are a number of files are only used by the subset of projects, but by including them in the shared project they're shared with all the heads, we would then need to use compilation directives so they're not compiled into the projects we don't want them to be.

@tomspilman

There is no finger pointing or who is to blame, its all about supporting our customers.

No blame here.... this stuff happens. As long as the issue will be addressed in a future release we are good for now.

@yishaigalatzer

@nigel-sampson I'm not suggesting to use an shproj. Instead I'm suggesting to move the csproj files to a separate folder and put the project.json next to them. Then link the source files.

This is just folder reshuffling which I think should work quite easily. Could you tell me if this works for you or are you still blocked?

@tomspilman thanks for the comment, I hope we can get enough traction to fix this quickly.

@nigel-sampson

Yeah this is working, we temporarily have the UWP project in a separate folder till this gets resolved.

Thanks

@CobraCalle

Adding hunderets of files by linking them can not be mouch more than a temp. workaround.

I would prefer a solution analog to the old packages.config files... just prefixing them with the project Name and thats it. I think the would be the most straight forward approach and should not be very complex to implement

@yishaigalatzer

@cobracalle We completely agree. We plan to do the first step in an upcoming release (NuGet will restore from {projectName}.project.json to {projectName}.project.lock.json. And for the UI to edit the right file when updating packages.

This also requires a change from the project system to a. pickup the right lock file in the build b. in PCL edit the right project.json file

@pilchie 's team is tracking it on their side

@emgarten emgarten referenced this issue in NuGetArchive/NuGet.PackageManagement Aug 19, 2015
Closed

{ProjectName}.project.json support for nuget.exe #73

@emgarten
Contributor

I have added support for projectName.project.json to nuget.exe and the Visual Studio 2015 extension.

NuGetArchive/NuGet.PackageManagement@de28a73
NuGetArchive/NuGet.PackageManagement@7d76fca
NuGetArchive/NuGet.VisualStudioExtension@7085049

@emgarten emgarten closed this Aug 21, 2015
@Pilchie
Pilchie commented Aug 21, 2015

Tagging @rchande and @jasonmalinowski too

@tomspilman

Fantastic @emgarten ! When can we expect this feature to get released?

@yishaigalatzer

We are still depending on a change in the c# project system. We will update further when that happens as it related to a visual studio release and not just a nuget release.

@onovotny onovotny referenced this issue in onovotny/ReferenceGenerator Aug 29, 2015
Closed

Support project-name specific project.json #5

@emgarten emgarten was unassigned by yishaigalatzer Sep 1, 2015
@emgarten emgarten assigned feiling and unassigned emgarten Sep 1, 2015
@feiling feiling added 3 - Done and removed 2 - Working labels Sep 1, 2015
@feiling feiling removed their assignment Sep 1, 2015
@BrianPeek BrianPeek referenced this issue in MonoGame/MonoGame Sep 3, 2015
Closed

VS2015 MonoGame compiling problem #4118

@tomspilman

FYI. The Windows 10 SDK Tools release includes the fix for this:

  • Added support for multiple csproj in one folder with project.json, with {projectName}.project.json support.

https://social.msdn.microsoft.com/Forums/en-US/e9df01f6-1474-4a4e-98fc-2567591c764f/update-11-release-notes-and-installation-instructions?forum=Win10SDKToolsIssues

@kjpou1 kjpou1 added a commit to mono/CocosSharp that referenced this issue Oct 25, 2015
@kjpou1 kjpou1 [project.json] Fix VS2015 compile problems. The issue is that even wh…
…en compiling non Windows Universal projects NuGet still tries to installs the .net Core 4.5 references from the project.json. This gives the following error: Microsoft.NuGet.targets(89,5): error : Couldn't find the required information in the lock file. Make sure you have .NETCore,Version=v4.5.1 mentioned in your targets.

Moving the project.json to be project specific solves this without installing any extra tools or updates.  See (NuGet issue 1102)[NuGet/Home#1102]

This is tested on a 5 day old VS 2015 RTM fresh install which still gives this error even after installing the windows tools 1.1 update.  The tools update did not fix the problems but this does.

+ Add NuGet *.lock.json files to .gitignore.
72a2620
@kjpou1 kjpou1 added a commit to MonoGame/MonoGame that referenced this issue Oct 25, 2015
@kjpou1 kjpou1 [project.json] Fix VS2015 compile problems. The issue is that even wh…
…en compiling non Windows Universal projects NuGet still tries to installs the .net Core 4.5 references from the project.json. This gives the following error: Microsoft.NuGet.targets(89,5): error : Couldn't find the required information in the lock file. Make sure you have .NETCore,Version=v4.5.1 mentioned in your targets.

Moving the project.json to be project specific solves this without installing any extra tools or updates.  See (NuGet issue 1102)[NuGet/Home#1102]

This is tested on a 5 day old VS 2015 RTM fresh install which still gives this error even after installing the windows tools 1.1 update.  The tools update did not fix the problems but this does.

This may cause conflicts in the future due to outstanding PR against MonoGame.
714885e
@nigel-sampson

Just an FYI for anyone else who runs into this gotcha.

  • For packages.config the supported pattern was packages.{project-name}.config.
  • For project.json the supported pattern is {project-name}.project.json.
@csharpfritz
Member

I'll get an entry into the docs to make this feature clear

On Feb 9, 2016, at 21:33, Nigel Sampson notifications@github.com wrote:

Just an FYI for anyone else who runs into this gotcha.

For packages.config the supported pattern was packages.{project-name}.config.
For project.json the supported pattern is {project-name}.project.json.

Reply to this email directly or view it on GitHub.

@rshackleton

This still seems to be an issue when using packages.config, not checked when using packages.json when using VS2015 Update 1. Are we still waiting on a fix on VS's side?

@Pilchie
Pilchie commented Feb 18, 2016

Tagging @jasonmalinowski too.

@nigel-sampson

Currently using both versions of this packages.config and project.json in Caliburn.Micro with no problems.

@magol magol added a commit to magol/dokan-dotnet that referenced this issue Aug 31, 2016
@magol magol Fix NuGet dependencies for multi target projects using {projectName}.…
…project.json introduced in NuGet 3.2. See NuGet/Home#1102
f2dfff3
@magol magol added a commit to magol/dokan-dotnet that referenced this issue Sep 7, 2016
@magol magol Fix NuGet dependencies for multi target projects using {projectName}.…
…project.json introduced in NuGet 3.2. See NuGet/Home#1102
827fd2a
@magol magol added a commit to magol/dokan-dotnet that referenced this issue Sep 7, 2016
@magol @magol magol + magol Multi-target to .NET Framework 4.0 and 4.6
 - Clone DokanNet.csproj to DokanNet.net4.6.csproj and target it to .NET
   Framework 4.6
 - Rename DokanNet.csproj to DokanNet.net4.0.csproj
 - Remove packages.config and replace with DokanNet.net4.0.project.json
   and DokanNet.net4.6.project.json (introduced in NuGet 3.2, see
   NuGet/Home#1102)
 - Handle extra flags in FileAttributes for .NET Framework 4.5
 - Update DokanNet.nuspec to handle the multiple targets.
7d9f617
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment