New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request - Support adding NuGet packages into WiXProj Projects (MSI project or WiXLib) #5861

Open
stunney opened this Issue Aug 7, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@stunney
Copy link

stunney commented Aug 7, 2018

I would like to create wixlibs based on packages that we store in our private package repository, both .NET and native projects included.

Right now when I try and do this I get an error

"Could not install package 'BLARH 1.0.0.0". You are trying to install this package into a project that targets 'Unsupported, Version=v0.0' but the package does not contain any assembly references or content files that are compatible with that framework, contact the package author"

Adding a package of any sort should not matter to a wixproj.

Thoughts?

@robmen

This comment has been minimized.

Copy link
Member

robmen commented Aug 7, 2018

Maybe follow up with the NuGet team since they'll understand what all that means?

@barnson

This comment has been minimized.

Copy link
Member

barnson commented Aug 16, 2018

We need more detail (including the info requested in the issue template). Can you share a .wixlib Nupkg that demonstrates the problem and the exact repro steps you took?

@stunney

This comment has been minimized.

Copy link

stunney commented Aug 20, 2018

Bugs

If this issue is a bug:

  • Which version of WiX are you building with?

3.11, 3.14.1703, 4.X (error occurs everywhere)

  • Which version of Visual Studio are you building with (if any)?

2017 Enterprise (15.8.0)

  • Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

0.9.21.62588

  • Which version of .NET are you building with?

4.5, 4.6, 4.7, C++ (Win32 Native)

  • Describe the scenario and benefits that the feature supports.

Being able to source content from a nupkg would be an amazing way to ensure that installers are 1) fast to build, 2) decoupled from application 3) more easily managed.

The teams I have worked on typically have a large number of applications (EXEs or Web Apps) that go into an installer. Instead of having crazy build/copy scripts set up it would be fantastic to simply go into the package management UI in the installer project and upgrade an application, test the installation, and check it in. Updating the wxs file's path shouldn't be a problem as an additional manual step, although it could easily be extracted out and automated as a wix variable of some kind $(.installpath).

I am trying to add a nuget package of ANY kind to a WiXProj project in Visual Studio. This way installers are easily upgraded and maintained.

Steps:

  1. Create new WiX 3/4 Library or Setup (.wixproj) project (error is the same, regardless of project version/type).
  2. Go to "Manage NuGet Packages..."
  3. Select nearly ANY NuGet package from NuGet.org
  4. The following error appears: "Could not install package 'BLARH 1.0.0.0". You are trying to install this package into a project that targets 'Unsupported, Version=v0.0' but the package does not contain any assembly references or content files that are compatible with that framework, contact the package author".
  • Describe how you're accomplishing the feature today (if possible).

For now, I would (read: not currently doing it) need a manually maintained packages.config file and pre-build steps to get all nuget packages for each application.

  • Describe what you'd like the new feature to do.

Allow for a wixlib to have any nupkg added, regardless of target frameworks, dependencies, etc. Just install them in a local packages folder. Maybe automatically add wixvars for Source location roots to eliminate the need to update wxs files on every upgrade.

At the end of the day, I want to promote packages to stable/release, not code. This will go a long way in doing that.

@barnson barnson added this to the v4.x milestone Sep 13, 2018

@barnson barnson added the enhancement label Sep 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment