Dilemma: Config updates in another project

Nov 11, 2011 at 9:53 PM

Here is my dilemma with many packages that need to update web.config or app.config; many times I want all the modifications and references added to a class library project but I still want web.config updated even though it is in a project other than the one I'm adding the package to. It is my understanding that the package installations are per project and may not be able to go cross project? I'm not sure if these packages are just not written well to consider this scenario, and assume that people will just write all the code in their main shell app? Or if it is more of a limitation of NuGet?

 

Installing the package to both projects doesn't usually work because I don't want references and other additions in the main web project, I just want web.config updated.

 

I suppose one could make config only packages but that would certainly clutter things up a lot. Maybe some sort of apply-packageconfig type command could solve this? Or what are others doing in this scenario? I had this problem with Glimpse recently and ended up temporarily installing the package to the web project, copying off the changes it made to web.config, then uninstalling from web project and re-applying the config changes.

 

Ideas?

Nov 12, 2011 at 12:50 AM

Yah, this is a current limitation of nuget. I don't know of any other package that needs to do the same. We will need to come up with a new concept in order to support this needs.

 

 

Nov 12, 2011 at 1:13 AM
Edited Nov 12, 2011 at 1:14 AM

Thanks, that is what I figured. I have run into this problem several times with other packages too such as NLog, where config adjustments are needed in the app project but logging is handled in another project.

 

In some cases adding the package to both projects works out okay, it really depends on what the package does. Usually though it results in an unneeded reference in one project and sometimes file additions that are unwanted.

 

One solution could be having some sort of "package installation options" where we could still install the package in multiple projects but in one project we might just want a web or app config update and in another references and file additions etc.  Otherwise it seems it might require some sort of solution level option with selective project picking. Either way it would require some user input as something as simple as a config update cannot be assumed as there could be multiple startup projects and multiple config files.

 

Well hopefully there will be something added at some point to address this and I'm open to suggestions for that as well as any suggestions until then.  Thanks

Coordinator
Nov 12, 2011 at 9:52 AM

For now, the easiest thing might be to simply install the package into multiple projects, then remove the assembly reference in the one project that doesn’t need it. It’s probably the same number of steps you’d take if we added a feature like the one you described. And the best part is, it’s easy to do today. J

Nov 12, 2011 at 11:49 AM

One possibility is to treat this as a cross-project dependencies. A package can specify a dependency on another package with a twist in that the dependency package has to be installed on a different project than the current project.

So the dependency element can look like this:

<dependency id="mypackage.config" version="1.0" type="external" />

In the Powershell console, you can type in the name of the external project. In the dialog, we show a prompt listing all projects in the current solution; you've gotta pick the external project.

Nov 13, 2011 at 7:40 PM

@Phil - Yeah I agree that installing into multiple projects and then undoing some of steps in one project is the best route today. Of course that has its inconveniences but yeah not a big deal:

  1. Undoing can be more than just removing a reference, might be multiple references, folder and file additions
  2. Not always immediately obvious what all changes were made by package install, particularly when there are other existing pending checkins
  3. Unclear what might happen if/when the package is updated later - i.e. not sure if I'd have to undo those same changes again on updates

 

@dotnetjunky - Interesting. I guess the downside to package developers doing that is it would force a split between projects and while some would like that in cases that would not always be desirable.

 

Thanks guys. I just wanted to be clear on NuGet's capabilities before assuming publishers are just creating their packages with too many assumptions.