exclude classes from build process

[Marco Zapletal]

hi list,

i have an c# project, which contains some additional classes (nunit
testclasses), which are not needed in a release build? is it possible to
exclude them in the release build process?

i dont want to put the nunit tests in another project, because then i
have to switch the access modifiers from internal to public for the
classes i want to test.

thanks,
marco

[Lasse Vågsæther Karlsen]

Marco Zapletal wrote:

hi list,

i have an c# project, which contains some additional classes (nunit
testclasses), which are not needed in a release build? is it possible to
exclude them in the release build process?

<snip>

You could wrap the entire class in the file in a #if DEBUG clause. The
files would still be compiled but they would not contribute anything to
the final assembly.

--
Lasse Vågsæther Karlsen
http://www.vkarlsen.no/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2

[Lasse Vågsæther Karlsen]

Marco Zapletal wrote:

hi list,

i have an c# project, which contains some additional classes (nunit
testclasses), which are not needed in a release build? is it possible to
exclude them in the release build process?

<snip>

You could wrap the entire class in the file in a #if DEBUG clause. The
files would still be compiled but they would not contribute anything to
the final assembly.

--
Lasse Vågsæther Karlsen
http://www.vkarlsen.no/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2

[Tim Haughton]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.no> wrote in message
news:en*************@tk2msftngp13.phx.gbl...

You could wrap the entire class in the file in a #if DEBUG clause. The
files would still be compiled but they would not contribute anything to
the final assembly.

I'd recommend wrapping in #if TEST instead, and creating 2 new
configurations, a release and a debug with tests enabled. In the two new
configurations, define TEST, and set everything else up as their none test
counterparts. The reason I suggest this is that there are some optimisations
in the release build that I have seen trip up a release but not a debug
build. It doesn't happen often, come to think of it I don't think I've seen
it happen since VS2003 was released, but since you're shipping a release
build, you should test it.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Tim Haughton]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.no> wrote in message
news:en*************@tk2msftngp13.phx.gbl...

You could wrap the entire class in the file in a #if DEBUG clause. The
files would still be compiled but they would not contribute anything to
the final assembly.

I'd recommend wrapping in #if TEST instead, and creating 2 new
configurations, a release and a debug with tests enabled. In the two new
configurations, define TEST, and set everything else up as their none test
counterparts. The reason I suggest this is that there are some optimisations
in the release build that I have seen trip up a release but not a debug
build. It doesn't happen often, come to think of it I don't think I've seen
it happen since VS2003 was released, but since you're shipping a release
build, you should test it.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Marco Zapletal]

thank you both for your answers...

regards,
marco
Tim Haughton wrote:

"Lasse V�gs�ther Karlsen" <la***@vkarlsen.no> wrote in message
news:en*************@tk2msftngp13.phx.gbl...

You could wrap the entire class in the file in a #if DEBUG clause. The
files would still be compiled but they would not contribute anything to
the final assembly.

I'd recommend wrapping in #if TEST instead, and creating 2 new
configurations, a release and a debug with tests enabled. In the two new
configurations, define TEST, and set everything else up as their none test
counterparts. The reason I suggest this is that there are some optimisations
in the release build that I have seen trip up a release but not a debug
build. It doesn't happen often, come to think of it I don't think I've seen
it happen since VS2003 was released, but since you're shipping a release
build, you should test it.

[Marco Zapletal]

thank you both for your answers...

regards,
marco
Tim Haughton wrote:

"Lasse V�gs�ther Karlsen" <la***@vkarlsen.no> wrote in message
news:en*************@tk2msftngp13.phx.gbl...

You could wrap the entire class in the file in a #if DEBUG clause. The
files would still be compiled but they would not contribute anything to
the final assembly.

I'd recommend wrapping in #if TEST instead, and creating 2 new
configurations, a release and a debug with tests enabled. In the two new
configurations, define TEST, and set everything else up as their none test
counterparts. The reason I suggest this is that there are some optimisations
in the release build that I have seen trip up a release but not a debug
build. It doesn't happen often, come to think of it I don't think I've seen
it happen since VS2003 was released, but since you're shipping a release
build, you should test it.