Cannot Add NuGet Package to WiX (Votive) Project

Mar 7, 2011 at 9:59 PM

Hi,

I noticed that I cannot add a NuGet package to a WiX setup project (http://wix.sourceforge.net/votive.html). When I right click, there is no option for "Add Library Package Reference". 

How would I go about modifying a WiX project template definition to support NuGet packages, or how could I introduce such a change into NuGet itself? What is the mechanism that NuGet or Visual Studio uses to determine the project templates that are supported for NuGet packages?

Thanks in advance!

- Joe Fitzgerald

Mar 7, 2011 at 11:07 PM

We don't support WiX project at this time. Currently we hard-code the list of projects that we support, which include C#, VB.NET, F#, WebApp and WebSite.

If you're interested in making the change to NuGet, you're welcome to create a fork of the source tree and send in pull request. This page can get you started: http://nuget.codeplex.com/documentation?title=Contributing%20to%20NuPack

Finally, just curious, what package are you adding to a WiX setup project? What does it do?

 

 

Mar 7, 2011 at 11:27 PM

The goal for a NuGet package for WiX projects would be to enable people to create and share reusable setup templates easily, and lower the barrier to entry for WiX. I mentioned this to Rob Mensching (creator of WiX), and he noted that you can enable reuse and templates using extensions and .wixlibs. 

The only issue with the approach he suggests: it requires an ultra-specialized skill-set to enable, and distribution is not addressed. My goal is to make this accessible to the average Visual Studio user.

Coordinator
Mar 7, 2011 at 11:51 PM

This is a very interesting idea. My recommendation is to create an issue and try to get someone interested in implementing it, if not yourself. Unfortunately, we have a lot of other bugs/features that will have a higher priority as we try and mature NuGet so we won't implement something like this any time soon, but we would welcome a patch from the community. :)

Mar 8, 2011 at 12:32 AM

Phil,

The issue is created (link). Intuitively, this feels like it mostly requires testing, with only a small amount of implementation. I'm open to working on it, but would obviously appreciate some pointers on where to look / make changes. 

At first glance, the only moderately difficult thing we'd need to do that is to prevent packages from adding references to assemblies. A 'reference' in a WiX setup project is really a mechanism to enable harvesting of files from another project. Only Content, Source & PowerShell assets should be allowed. Is that possible in the current architecture?

Cheers,

-Joe

Developer
Mar 8, 2011 at 1:42 AM

Supposedly you'd need to write a WixProjectSystem (example here http://nuget.codeplex.com/SourceControl/changeset/view/91b54d3dd480#src%2fVisualStudio%2fProjectSystems%2fVsProjectSystem.cs), that knew how to do wix specific actions. NuGet in it's current form doesn't support non dll/exe references so I'm not sure what would happen there. You can always throw in the AddReference implementation of your project system but that'll just leave things 1/2 installed (it can always be uninstalled).

Mar 9, 2011 at 6:35 PM

DFowler,

Actually, you'd want to prevent references from being added at all. It is the responsibility of the user to add references to other projects, but this is primarily just to establish build dependency. Unfortunately, the way that Votive projects currently work, they will only package the primary output of a referenced project (as opposed to the primary output, as well as any locally copied references), so in order to include everything you need, you need to drop down to msbuild and do some creative copying of files. This is an aspect that I would like to fix in a reusable way (the other being the content of .wxs, .wxi, .wxl files themselves).

You'd be looking to enable NuGet packages that include Content / Source (msbuild, .wxi, .wxl, .wxs, .txt, .ps1 files), and to prevent the packages from adding references. 

I looked through the various project systems. Where is the hard-coding that ensures you can only right click on projects created with C#, VB.NET, F#, WebApp and WebSite project templates? 

My assumption is that I can create a WixProjectSystem that ignores references by overriding AddReference (do nothing), RemoveReference (do nothing), and ReferenceExists (always return false). But - how do I enable the 'Add Library Package Reference' for this project type, and what is the mechanism by which I would identify a WiX project? I noticed that in the solution file, all my WiX projects have a Guid of {930C7802-8A8C-48F9-8165-68863BCCD9DD}, while class libraries have a Guid of {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}. Am I heading in the right direction??

Thanks,

-Joe

Developer
Mar 9, 2011 at 6:42 PM

Take a look at:

VsConstants.cs - Add the Guid here for the Wix project type

ProjectExtensions - add that guid to the _supportedProjectTypes member.

Mar 10, 2011 at 12:29 AM

Initial implementation is done (http://nuget.codeplex.com/SourceControl/network/Forks/joefitzgerald/WixProjectSystem), and I was able to add a HelloWorld package (with HelloWorld.txt content file) to the WiX project successfully.

When is appropriate to submit a pull request?

Developer
Mar 10, 2011 at 12:39 AM

How much testing did you do? We don't really want to take changes like this that aren't *fully* tested. We need to know what works and what doesn't work before we look at this pull request.

Mar 10, 2011 at 12:46 AM

Is there a representative set of NuGet packages that I could add to this to ensure that appropriate testing is done? Some test cases I can run through? In lieu of that, I might try with the top 10-20 packages.

It's important to note that any package that includes a reference will inherently not have that reference added, by design. Consequently, we're really testing file add / remove, ps1 execution, source control operations.

If there were a way to filter packages in the Add Library Package Reference dialog to only show those packages that don't have references, that would be ideal, but that's a fundamental shift in the way that packages are categorized / discovered, and a much bigger discussion.

Developer
Mar 10, 2011 at 12:49 AM

We have functional tests but none of them include WixProjects (obviously), more details here : http://nuget.codeplex.com/wikipage?title=Functional%20Tests.

I don't know of those packages off the top of my head but we do have some test packages in: test\EndToEnd\Packages that cover some of those scenarios.

Mar 11, 2011 at 7:35 AM

David,

I've done a fair bit of testing (using WiX projects and standard class library projects) and introduced changes in my fork associated with this. In testing all of the packages in test\EndToEnd\Packages, there are two known issues (although I think only one is an actual issue):

  1. [Potentially Not An Issue] PackageWithNonExistentGacReferences installs successfully because we don't allow GAC references for the WixProjectSystem (i.e. we do nothing when a caller calls the AddGacReference method.
  2. [Issue] When uninstalling packages with content files (e.g. PackageWithRootNamespaceFileTransform), "The path is not of a legal form" is displayed in pink text in the 'Add Library Package Reference' pop-up dialog when you select uninstall. It does not show up in the Output window for "Package Manager'. In debugging this, I traced it to ProjectExtensions.GetProjectItem(string path), and the path is empty. It also seems to show up when FileSystemExtensions.DeleteDirectorySafe is called. Any help / advice here would be much appreciated.

Also - I've tried to cancel my pull request, but it just hangs, saying "Saving". Can someone help me cancel it?

Cheers,

-Joe

Coordinator
Mar 11, 2011 at 4:20 PM

I cancelled it by declining it. You can issue a new one at any time.

Apr 2, 2011 at 1:52 AM
Edited Apr 2, 2011 at 1:54 AM

I see that Drew indicated in my pull request that he'll try to pull this into 1.3 after reviewing the code. Please let me know what I can do to help, and feel free to point me in the right direction if I'm not following the right process.

Cheers,

-Joe

Apr 2, 2011 at 1:57 AM

Joe, I commented on the pull request on Mar 22nd explaning that it was too late in the 1.2 schedule for us to do the testing on our side to get it into that release. Now that we've shipped 1.2, we'll start our testing of your changes and see if we can get it in for 1.3.

Did you not get a notification of my comment on the pull request? We might need to let CodePlex know there is a notificaiton bug.

Apr 2, 2011 at 2:03 AM

Drew,

I didn't get notified, but I amended my comment above as soon as I realized you'd commented on the pull request. My bad for not looking there first!

Cheers,

Joe

Coordinator
Apr 2, 2011 at 3:32 AM

Did you submit a code review? 

http://nuget.codeplex.com/wikipage?title=Code%20Reviews I looked at your code changes and they seem minimal enough. In general we require a code review. I'll let the devs who review the code determine whether we need it or not in this case.  Based on my quick glance, it looks good to me. :)

Also, of our coding guidelines are at the bottom of this page: http://nuget.codeplex.com/documentation

Apr 2, 2011 at 3:40 AM

Phil,

No; I signed up for the code review site, but decided it was a fairly small change so went for the pull request instead. Happy to put it through review if needed.

RE: coding guidelines, I made sure to follow them as I made changes (was a little unnatural to put braces where specified, but I did it anyway :)).

Cheers,

Joe

Coordinator
Apr 2, 2011 at 3:53 AM
You're probably right about not needing a code review :) I think we should accept this change. You're going to maintain it, right? ;)
>
Developer
Apr 2, 2011 at 6:02 AM

I started to pull in the change last night, dont worry I'm working on the merge. There are some minor modifications that I'm making and running our end to end tests to make sure nothing has regressed. After that it should be good.

Developer
Apr 2, 2011 at 7:57 AM

I accepted the pull request, please try it out on default.