PackageReference with Package build injection.

[bbowman]

will PackageReference support the ability to use one nuget package's build injection when describing a second PackageReference? The crazy scenario I'm thinking about is using @kzu 's https://github.com/kzu/GitInfo/ to construct a package dependency version based on the current git tag to solve some local development / CI issues with picking up the latest package. @natemcmaster may be interested here too.

I'm guessing that my scenario won't work based on what I know about MSBuild but I'm also very curious how you guys are handling the injection of .props / .targets mid build.

[emgarten]

This is explicitly blocked at restore time to avoid requiring multiple restores. Package dependencies need to be defined in the nuspec.

See #4013 for more info

[bbowman]

@emgarten Slightly different ask here. I was hoping to do something "fancy" where the version of a package I depend on is influenced by my current branch. For instance, when building master branch to ship externally (perhaps as an app not even as a nuget package), it would be nice to switch over all my dependencies to stable ones. When building develop, though, it would be nice to depend on the latest pre-release packages to make sure regressions / incompatibilities are caught as soon as possible.

https://github.com/kzu/GitInfo/ allows MSBuild to know about Git but this wouldn't be there at restore time unless multiple restore passes are allowed. I suppose I could re-create that functionality by locally restoring to a different spot in my repo as a pre-restore step? I'm not sure how you guys are hooking in here (perhaps via a VSIX to know a build is requested, doing a fake build to restore and then the real build?) ...

Alternatively, to start out, I'm only really worried about other locally produced packages having this functionality so is there a way with PackageReference to reference a local project path to always build and restore a local project (specified with the path to the project that produces the nupkg) at restore time? This would solve a number of other issues in our current setup but that also seems pretty hard to accomplish. My suggestion there would be to allow a PackageReference to not include a version but rather a path to the producer and the built artifact of that project would allow the client to see the version. thoughts?

[emgarten]

but this wouldn't be there at restore time unless multiple restore passes are allowed

This is the same ask. If a new PackageReference appeared after restore completed you would need to restore again.

I suppose I could re-create that functionality by locally restoring to a different spot in my repo as a pre-restore step?

Yes, that would be a good way to do this, and at that point it is all MSBuild. Restore just evaluates the project to find all PackageReferences. You can hook this up in your project however you want, it just can't rely on things downloaded by restore since those won't be there at the time restore reads the PackageReferences.

You can run nuget.exe install to get the package on disk ahead of time and reference it directly in your project or a targets file.

[bbowman]

@emgarten any comment on the local PackageReference idea?

[emgarten]

any comment on the local PackageReference idea?

@bbowman I'm not clear on what you are asking for there. You want a reference to a project?

[bbowman]

@emgarten @mishra14 @rrelyea I am envisioning extending https://github.com/NuGet/Home/wiki/PackageReference-Specification as follows:

<PackageReference Include="..\Path\To\Project\That\Generates\Package\project.nuproj">
...
</PackageReference> 

That would would help with the project/package duality. The idea being that at restore time, it would build the project at the path and use the produced package in the restore.

Alternatively, I could see:

<ProjectReference  Include="..\Path\To\Project\That\Generates\Package\project.nuproj">
...
</ProjectReference>

being used in the restore target (I suppose it would key off the nuproj or the nuproj itself would build itself and report that as a child package dep to the restore target)?

Basically within the same solution/repository I'd like to be able to describe a dependency to a package that is also built in the solution.

[davidfowl]

That would would help with the project/package duality.

We plan to support this via project references.

/cc @srivatsn @dsplaisted

[bbowman]

@davidfowl @emgarten is this active in VS2017 RC? I'm seeing some weird build behavior in my nuprojs in 2017 only and I'm wondering if this could be related now.

[emgarten]

@bbowman a project reference will be read as a project, there currently isn't support for creating a nupkg first and then using that.

[jjanuszkiewicz]

(I added the same comment to https://github.com/dotnet/cli/issues/6306, but it's closed so commenting here as well)

@emgarten Microsoft has already announced that "Package project duality" is available, but I can't find any relevant examples or other information. Can you help me figure out what's supported?

[emgarten]

@jjanuszkiewicz duality in the linked blog post is referring to how the assets are consumed by the parent project, this isn't referring to automatically changing between projects and packages based on whatever is available. You can get that behavior by adding conditionals to your MSBuild project.

[kzu]

Here's an example of how I'm doing exactly that: conditionally reference binaries (could be project references instead as easily) vs package references depending on the presence of the binaries (could be the source projects, or whether it's debug or release builds, or whatever): https://github.com/kzu/roslynator/blob/master/Directory.Build.targets

[pchalamet]

I've been developing a tool named full-build (see http://full-build.io or https://github.com/full-build/full-build for more info) that basically allows switching between projects or binaries in a workspace. It dates before PackageReference hence it uses targets files to switch between ProjectReference and Reference (the latter simulates project reference behavior but with pre-built binaries).

All in all, it does work but I really would like to switch to ProjectReference and PackageReference only as this really looks cleaner.

So my question : do you think msbuild will behave exactly the same when using the package from a project (PackageReference) or the project itself (ProjectReference)? I mean, is project/package duality expected to work for this?

[kzu]

Well, for one thing, if the referenced project/package includes build targets, those wouldn't be imported automatically, I think. If would be particularly tricky if those build artifacts are produced as part of building the project, since you'd need to build the project reference, then import the new targets into the referencing project, then refreshing/reloading it mid-build (since you got to build the project reference as part of the project-to-project reference processing) and re-evaluate (or re-build without building project references?).

If those targets reference build tasks that are produced by the referenced project, even worse, since now you'll get the previous version (assuming you had it imported in the referencing project from a previous build) locked and the build would fail.

Bottom-line: I think it can be made to work for some subset of happy-paths, but there will most likely be a gazillion unsupported scenarios :(

[pchalamet]

I guess it's not much a problem the way full-build works. The only things I'd like to validate is if a package from a project behaves the same as the project itself when imported. Msbuild as specific behavior when ProjectReference is used (like recursive copying of dependencies and content as far as I remember).

It's been announced package behavior is same as project for consumers - Is it really true? Can ProjectReference and PackageReference be swapped and msbuild will keep same behavior?

[rrelyea]

Per @emgarten, conditionals in msbuild are you best way for duality today.

[kabua]

To support Package/Project duality, I would propose something like the following:

    <PackageReference Include="ProjectA.BL" Version="1.0.3">
      <ProjectReference Include="c:\repo\projectA\ProjectA.Business.csproj" />
    </PackageReference>
    <PackageReference Include="ProjectA.Common" Version="1.0.3-DebugWithSymbols">
      <ProjectReference Include="c:\repo\projectA\ProjectA.Common.csproj" />
    </PackageReference>
    <PackageReference Include="ProjectA.DAL" Version="1.0.3">
      <ProjectReference Include="..\ProjectA.DataAccess.csproj" />
    </PackageReference>