Specifying the solution's configuration specifies the sub-project's configurations instead

[Jesse Dickey]

When starting the NUnit GUI from the command line, you can specify a configuration. If you are doing this with a solution instead of an individual project, it does not work correctly. It assumes that all the projects have the same configuration name as the solution configuration. While this is often true, it is possible to have a solution configuration that uses project configurations of a different name.

If you need more detail, this is how I have my project set up in Visual Studio 2008. I use the Configuration Manager under the Build menu to organize my configurations. I have a solution configuration called "Test". Some of the projects under this solution do not even have a configuration called "Test". For these projects I have the "Test" solution configuration using the "Debug" version of those projects. When I load the NUnit GUI using the command line and pass it the location of the solution file and instruct it to use the "Test" configuration, it only loads the projects with a configuration called "Test" and therefore is ignoring the solution configuration settings.

[Charlie Poole (charlie.poole)]

The /config option refers to configurations stored in an NUnit project, which may or may not map to VS configurations.

When you open a VS project, NUnit creates an in-memory NUnit project, which includes all the configs found in that project. This is usually what is wanted, but if you required something different, you could edit the config and save it as a .nunit project file.

Similarly, when you open a VS solution, NUnit creates an NUnit project, which includes all the projects found in that solution whose project type is understood by NUnit. As you noticed, it's just the union of all the configs in all the projects used.

I agree that it would make sense for NUnit to use the config information in the solution file. I'm characterizing this as a new feature we should try to get into a future release.

In the meantime, I suggest you open your solution and save it as an NUnit project. You can edit the NUnit project by hand or in the project editor to get the configs set up the way you want.

[Jesse Dickey (jessedickey)]

Thanks for the help in understanding this issue. I will try saving an NUnit project as you suggested. It still seems more like a bug than a missing feature to me though. If you still think this is a feature request I won't make a fuss about it. I am just glad you want to implement this, but I also want to help you think about things from a user perspective. Thanks for working on this open source project!

Here is my reasoning on why this seems like a bug, from a user perspective:

The fact that specifying a configuration merely refers to the NUnit project configuration rather than the solution configuration sounds more like an internal implementation detail than an intended external behavior, especially since it is creating the NUnit project in memory and (somewhat) adapting it to the solution.

Looking to the documentation found here http://www.nunit.org/index.php?p=guiCommandLine&r=2.5.2 it makes it seem like you are specifying the .csproj configuration, not an NUnit project configuration. I say that because it does not even refer to the creation of an NUnit project, and even though it does not cover solutions, the lack of covering solutions implies that they work the same way, that is, referencing the configuration for that solution.

From a user standpoint, it definitely seems like you are referring to the solution configuration when use something like "nunit nunit.tests.sln /config:Release"

[Charlie Poole (charlie.poole)]

Hi Jesse,

Having called it a feature doesn't mean it's any less important
or lower in priority. We call things a bug if our code tries to
do something but doesn't work correctly. Since we never even
considered using solution configs it's something new that
we have to design and implement. Calling it a feature helps
in organizing who will do the work.

In this case, I gave it "wishlist" priority, which is fairly
low. That's because (1) it has worked this way for a long time
without anyone noticing it, (2) it's a change that breaks how
NUnit currently works, which could be surprising and (3) there
is a workaround for dealing with it. You may want to argue
about that rather than whether it's a bug or a feature. :-)

I do agree that the docs could say more about this. In fact,
there is not much on the page you reference about how solutions
are loaded, which leaves it up to you to make assumptions. That's
definitely a Bad Thing and I'll fix it for the next release.

Charlie

> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On
> Behalf Of Jesse Dickey
> Sent: Saturday, December 05, 2009 9:57 AM
> To: <email address hidden>
> Subject: [Bug 492674] Re: Specifying the solution's
> configuration specifiesthe sub-project's configurations instead
>
> Thanks for the help in understanding this issue. I will try
> saving an NUnit project as you suggested. It still seems more
> like a bug than a missing feature to me though. If you still
> think this is a feature request I won't make a fuss about it.
> I am just glad you want to implement this, but I also want to
> help you think about things from a user perspective. Thanks
> for working on this open source project!
>
> Here is my reasoning on why this seems like a bug, from a user
> perspective:
>
> The fact that specifying a configuration merely refers to the
> NUnit project configuration rather than the solution
> configuration sounds more like an internal implementation
> detail than an intended external behavior, especially since
> it is creating the NUnit project in memory and (somewhat)
> adapting it to the solution.
>
> Looking to the documentation found here
> http://www.nunit.org/index.php?p=guiCommandLine&r=2.5.2 it
> makes it seem like you are specifying the .csproj
> configuration, not an NUnit project configuration. I say that
> because it does not even refer to the creation of an NUnit
> project, and even though it does not cover solutions, the
> lack of covering solutions implies that they work the same
> way, that is, referencing the configuration for that solution.
>
> >From a user standpoint, it definitely seems like you are referring to
> the solution configuration when use something like "nunit
> nunit.tests.sln /config:Release"
>
> --
> Specifying the solution's configuration specifies the
> sub-project's configurations instead
> https://bugs.launchpad.net/bugs/492674
> You received this bug notification because you are the
> registrant for NUnit V2.
>

[Charlie Poole (charlie.poole)]

Postponed to 3.0