Dilemma: Config updates in another project

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.

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

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

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:

<dependencyid="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.