By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,165 Members | 849 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,165 IT Pros & Developers. It's quick & easy.

exclude classes from build process

P: n/a
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
Nov 17 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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
Nov 17 '05 #2

P: n/a
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
Nov 17 '05 #3

P: n/a
"Lasse Vgsther 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

Nov 17 '05 #4

P: n/a
"Lasse Vgsther 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

Nov 17 '05 #5

P: n/a
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.

Nov 17 '05 #6

P: n/a
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.

Nov 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.