NuPack needs to support config transform agnostically of the config file name

Oct 25, 2010 at 6:45 PM

This is a discussion of the bug:

Depending on the application type, the Configuration file could either be web.config or app.config.

We need a way to specify config changes that get applied to "whatever is the right config file for the project". Right now you have to assume the file name in the package, so you can't have it work for both web.config and app.config.

Currently, to transform web.config, you add a file to your package named web.config.transform. For app.config, you do app.config.transform.

Perhaps, as a shortcut, we could simply have config.transform which would apply to both web.config or app.config depending on your project type.


Oct 25, 2010 at 6:58 PM

Seems reasonable, except it's hard to discover when authoring a package.

Would it be crazy to say that you can call it either app.config or web.config, and in either case we'll apply to to both situations?  Having both should just be illegal.  Benefits is that it just works without having to learn a new trick, and that existing packages become magically fixed.

Oct 25, 2010 at 7:46 PM
config.transform FTW! I like it, it reduces repetition.

Let me throw out the devil's advocate though. Would there be a time you would want the config to be updated differently for an application versus the web? As in there is something different you might do in the web config based on configuration? Update a certain setting that only applies to web?
"Be passionate in all you do"

Oct 26, 2010 at 6:52 PM

Yeah, what Rob said is my concern. It's quite possible that you may want slightly different configuration depending on whether you're installing into a web app or a WPF app. Hence it should be legal to have both app.config and web.config.

Oct 26, 2010 at 6:56 PM

Right now we create x.config if it doesn't exist, do we want to keep that logic if you can have both? 

Oct 26, 2010 at 7:02 PM

One option is to allow all 3 files:

  • config.transform: always applied.  Affects either web.config or app.config depending on app type
  • web.config.transform: only applied for web apps, and affects web.config
  • app.config.transform: only applied for non web apps, and affects app.config

So e.g. if you have all 3, two of them end up being applied in a given scenario.

Oct 26, 2010 at 7:06 PM

That assumes we can detect a web app.

Oct 26, 2010 at 7:17 PM

Well, that assumption existed before my latest proposal.  The whole premise of this thread is that we can detect this.

Oct 26, 2010 at 7:22 PM

Well, we could say that we never create the target file for transforms. That way we never have to detect but the user creates which ever file they want us to modify (if it doesn't already exist).

Oct 26, 2010 at 7:22 PM

Well can we? We might be able to via a few simple rules right?

Does the current project:

  • Reference System.web?
  • Include an App.config file (if so, then it's not a web app)
  • Have the project type set to one of the web project type GUIDs
  • etc.

On the other hand, if you're installing it into a web app, why wouldn't you already have a web.config? Maybe we shouldn't auto-create it. That would simplify things.

Oct 26, 2010 at 7:24 PM

Well, that's now four posts in a row that start with 'well', that can't be good ;)

Oct 26, 2010 at 7:25 PM

Checking the project type GUIDs is the best option IMHO. I often mix and match assemblies and config files in and out of web/app projects (for example unit testing). The GUID is guaranteed and fixed and easy to pluck out (either through the API or other means). Relying on the existence of a file (like web.config) might fail in some cases (several apps I maintain don’t have web.config files but are web apps)

Oct 26, 2010 at 7:36 PM

What's the project type guid for a website/webapp (or thing that supports web.config).

Oct 26, 2010 at 7:40 PM

I'm confused by the question. The link you provided lists both web application and web site. Those are the only project types that I know of that support a web.config file.

Oct 26, 2010 at 7:42 PM

I think we just have to test this out. I'm sure mvc has it's own project type guid. My biggest concern is blocking scenarios that would otherwise work if not for this boundary.

Oct 26, 2010 at 7:48 PM

Agreed it should be tested. I just wanted to keep it simple rather than trying to come up with a code solution that would look at 8 different factors to determine if it was a web app or not.

Oct 26, 2010 at 8:11 PM
Edited Oct 26, 2010 at 8:11 PM

MVC projects have:


These are:

  • The MVC GUID
  • The Web App GUID
  • The Windows (C#) GUID

So presumably, if we can enumerate them all, we can rely on the Web App GUID to cover MVC.


Oct 26, 2010 at 9:52 PM

That’s correct. MVC is a “flavor” of the web app project type. Any WAP project type would have the WAP GUID.

Oct 27, 2010 at 10:54 PM

There are cases where you only need config for web, but not non-web (example: ELMAH's config consists of http handlers/modules and in a client app, doesn't necessarily need any config).

After discussion, we think we should keep this simple for consumers at the cost of a potential little extra work for package creators:

  • web.config.transform: only applied for web apps, and only affects web.config. Will create a web.config if it doesn't exist, but only for web apps.
  • app.config.transform: only applied for non-web apps, and only affects app.config. Will create an App.config if it doesn't exist, but only for non-web apps.

Note: This assumes we have good web vs non-web detection.