Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 638
  • Last Modified:

Debug Assert failure when building project

Folks - totally baffled here.  I have some Debug.Assert statements in private get Property accessors (before throwing an exception - used when getting and the property hasn't been set yet).  pretty standard stuff.

when I build (Release config), all of these Asserts get hit and I get the pop-up assert message.
This happens both in VS and MsBuild

how is it possible that:
1. Debug.Assert asserts when building?!?!
2. Debug.Assert would assert in a private get?

its as if the build is trying to access the private get?  does it have anything to do with the class, which inherits from System.Workflow.ComponentModel.Activity?
0
sfun28
Asked:
sfun28
  • 12
  • 7
1 Solution
 
Michal-DrozdCommented:
I have solution for you

Explain:
It is not common to include asserts in release.

Solution:
Note that calls to the Debug.Assert method disappear when you create a Release version of your code. That means that the call that checks the balance will disappear in the Release version. To solve this problem, you should replace Debug.Assert with Trace.Assert, which does not disappear in the Release version
0
 
sfun28Author Commented:
Asserting and Tracing are two different things.  I think you are misunderstanding the problem.  Debug.Assert is only active in Debug builds.  I'm doing a release build and hitting the assert.  Anyways, asserts shouldn't trigger when building, they should trigger when your code gets run.
0
 
Michal-DrozdCommented:
do you use your custom debug asserts right ? and you are trying to build release with these debug asserts right ?
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
Michal-DrozdCommented:
Problem is that Debug classes arent included (linked) in release. So building release with debug asserts in your code can cause many issues.
0
 
sfun28Author Commented:
I'm trying to figure out why the Assert is fired when I build.  Asserts should fire when you run code, not when you build code.  These are normal Debug.Assert() statements.   I am building release build, but that shouldn't matter.  the compiler will just ignore.  I have Debug.Assert in release builds all over my code and it works just fine.  In this particular case, BUILDING is causing the assert to fire, which is something I've never seen before.  I think it has to do with Windows Workflow.
0
 
Michal-DrozdCommented:
As i mentioned in last comment. Compiler (for .NET) cant build release becouse it cant find Debug classes (becouse release dont include them). So it is why thare are issues during building. I have met with similar problem in my projects, I am sure with it.
0
 
Michal-DrozdCommented:
when you use Debug.Assert(...) in code, compiler is (during building) trying to find Debug class in include path. But compiler cant find it, so it is asserted during building.
0
 
Michal-DrozdCommented:
If you need to use the Debug methods in a C# or Visual Basic Release build, you must define the DEBUG symbol in your Release configuration so Debug class should include during building
0
 
sfun28Author Commented:
so how do I fix this?  I have other projects with Debug.Assert and it works just fine in release builds.  How do I include the right resources in the path to make this problem go away?
0
 
Michal-DrozdCommented:
please read my last comments (i added several)
as i mentioned
try define DEBUG (somewhere at beginning of your source code):
#define DEBUG

Open in new window

0
 
Michal-DrozdCommented:
or as I mentioned replace Debug.Assert with Trace.Assert

and it will work for 99%
0
 
sfun28Author Commented:
sorry...but i'm still confused.  I don't need Debug methods in release build...i just need them in debug build.  But I don't want to remove them from my code otherwise they will not appear in debug build.  how do you propose that I use Debug.Assert?
0
 
sfun28Author Commented:
Visual studio has a property called "Define DEBUG constant"  I tried that but it didn't work.  I don't think this is the right solution to the problem.  #define DEBUG is for compiler directives.
According to the MS website:
By default, the Debug.Assert method works only in debug builds. Use the Trace.Assert method if you want to do assertions in release builds.

If this is true, then why are my assertions being fired in Debug build?

0
 
Michal-DrozdCommented:
ohh, sorry use following and your problem should be solved:

// in VB.NET
#Const DEBUG = False
 
// in C#
#undef DEBUG

Open in new window

0
 
Michal-DrozdCommented:
True is, debug asserts should be ignored when you use release, and should be working only in debug mode. You just can play with DEBUG constant (in last comment)
If DEBUG is not set (or false), debug asserts should be ignored in all mods (debug and release).
0
 
sfun28Author Commented:
that worked!  but what did it actually do?  why do I have to undefine DEBUG?  Will Debug.Assert work in debug builds?
0
 
Michal-DrozdCommented:
There is somewhere problem, some code or setting in VS.NET which set DEBUG to true during release. As i mentioned in last comment DEBUG constant is what is deciding to include debug asserts or not. And in release it should be undefined(set to false) in background automatically by .NET Framework.
0
 
sfun28Author Commented:
So I should really find out what the problem is.   Hmm...because if I keep #undef DEBUG then Assert won't work in Debug build, correct?
0
 
Michal-DrozdCommented:
yes

if you want asserts you must remove #undef DEBUG line
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 12
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now