I am getting the following type mismatch error on the following
IF obj.propery THEN
...
END IF
the code I am using is on visual source safe and when other developers run the same project the code runs with no error. The property is actually a string which is where the problem could be. When I debug and test the property i.e.
?obj.propery = True
no errors are thrown which is a bit strange. If I place the cursor over the property it says "True". I have done a bit of searching on the matter and have found that this may have something to do with OPTION STRICT, however I have the same version of the code as the other developers and OPTION STRICT is not OFF, it hasn't been altered in the code at all. Are there any other settings that could affect this execution of code at run time?
It strikes me that there could be an entirely different reason for your Type Mismatch error, especially as you are accessing an object property. I've experienced this error when I have, for some reason, been pointing at a different DLL to that registered. You will find with VB that it registers a DLL "on the fly" when you build it, so you may end up accessing the code somewhere that you did not expect. This may not be the problem in your case, but it is worth exploring.
This was nothing to do with VB6, it was to do with XP Mode and using my user account from another domain as opposed to XPMUser. When I use XPMUser the application runs this is very odd and I am not sure why this is. If anyone has the reason I would love to hear.
So you are sure this is not the case of a boolean being Vrai?
I'd be inclined to be more explicit in your IF condition
IF isempty(obj.property) = false AND isnull(obj.property) = false
BUT
it would be prudent to check that obj isn't null first, before you start accessing its properties....
Related
I'm having a weird problem with Visual Studio 2010 Ultimate:
One of my Nunit(2.6.2) test cases is failing in the debug mode but passing in the run mode, as if we had completely different code paths for the two scenarios.
Is this a known bug? or is there some option in vs I'm missing?
Please enlighten me!
Thanks a lot.
EDIT - MORE INFORMATION
My application submits some requests to a dll written by a group of people within the organization. The dll does some computation and returns the results back to me.
In a test case exploring the dll's behavior (e.g. submit a request having certain parameter, check the dll's output), running the Nunit test works fine, but debugging the test case gives me an error - an exception was thrown from within that dll.
IMPORTANT: Running/debugging another test case gives me consistent results.
So, for the weird test case:
1, either the dll is good, and something under the debug mode breaks the dll
2, or, the dll has a bug, which is triggered by something under the debug mode.
To my knowledge, the ONLY difference between running and debugging a piece of code in visual studio is that, when debugging, a pdb file is loaded while when running it's not. Essentially, a symbol table is loaded to identify code execution.
Then the issue doesn't make sense in the first place - why would loading a symbol table affect the dll's behavior? (It's unfair to ask anyone to give an explanation without seeing any code; however, since it's corporate prop. code, I can't show it here. Please, if you've ever encountered such things in your career, do share with me what happened in your case - let's hope my problem has the same cause so that I can actually know what went wrong. Thanks)
Are you using code coverage?
If so, try disabling it and run. It will probably work.
For more details, check: http://social.msdn.microsoft.com/Forums/en-US/aba3d58f-f19f-4742-b960-8ac2be29bb88/unit-test-passes-when-in-debug-but-fails-when-run
You may have run into a situation where you're taking the same code path, but the results are subtly different in debug vs non-debug due to optimizations. There are a couple of distinct possibilities here:
Your code has a subtle bug, e.g. a race condition
Your test is being overly specific, e.g. for floating point comparisons where you should use a tolerance
It's a pain not being able to debug, but I suggest you add logging throughout the method and the test so you can see what's going on. (And hope that the logging itself doesn't change the test result, which is also possible...)
Thank you for your response.
I've identified the reason: it's due to a false parameter which drives the dll nuts. My bad.
It still doesn't answer the question why the behavior at debug time goes crazy, but good while running the test case.
However, I guess, since the parameter is wrong in the first place, I can't really blame the dll for going nuts. Anyway, when I passed in the correct param, all went good.
Thanks a lot guys.
I'm currently dealing with a part-time (and annoying) bug with some extension methods in VB .NET (VS 2010 and VS 2008).
I have some client projects that use some extension methods from a "Framework" Project I created for general purpose.
However, sometime, when a try to start the solution, I get a long list of error saying the extension method "is not a member of" target object.
When this happen, I can rebuild the solution without getting any error but if I start the project again, the same error will be raised again.
So far I have 2 workaround
A) Go on the extension method definition, delete the tag, compile (with error), put the tag back.
B) Close Visual Studio et re-open it.
Is there any betterway to handle this problem?
There is an active bug report for this problem at Connect. There's a dire need for a repro, a project with specific steps to let them reproduce the issue in-house. Perhaps you can help, it's what it will take to solve it or recommend a workaround.
EDIT: one late addition to this answer, since I've posted this there have been additional questions that note a problem with the IntelliSense parser behaving different from the compiler. There's an issue with the multi-targeting feature, particularly in VS2010, triggered by the Client Profile option for .NET 4. It is the default for a new project. What goes wrong is adding an assembly reference that requires the full profile, commonly because of a dependency on System.Web. You'll get a warning for that, but that's quickly blown away with a large number of errors. The fix is to change the project's Framework Target from client to full.
I've recently encountered this same issue. My project would Build just fine but if I tried to use the Rebuilt option I would get the error about my extension methods not being found on the objects they were extending.
I have managed to fix this today by including an Import at the top of the classes using the Extension method.
So at the top of the file I actually have
Imports project_name.extension_module
I have no idea why this is required but it fixes the problem in my case. I hope this helps somebody else that has wasted as much time with this as I have!
Liam
A less time consuming work around than the two you listed is to "Rebuild Solution" instead of the normal Build Solution. This has always worked for me whenever I run into this problem.
We have something very similar. Call extensions merhod that extends type A. type is actually an instance of type B that implements interface C. interface C has a method with the same name as extension method.
Interface C declares method Foo
Class B inherits from A implements C
Static Class
Static method Foo (this A)
If A is C
(A as C).Foo
When debugging on the line if A is C it actually calls Foo multiple times and you can step at assembly level and see it indicates it is doing the comparison. The way we demonstrate that the call is happen Foo executes a sql statement and we can see sql profiler executing the code in Foo.
Change A as C to reflection and bug goes away. Or use debugger hidden/step through and bug is masked. Also if you micro-step the sql profiler shows the query is getting called multiple times (before Foo is actually called) for each assembly statement.
I would like VS2010 to ignore an error in XAML Code. The Reason is, it's not a real error, I have a own class of Windows and VS is not able to create an instance of it. So now it always shows "Can not create an instance of "ChildWindow"". This would not be bad, but it marks the hole file as error, and this looks realy ugly.
So: I would love to tell him to ignore the ChildWindow error, but show other errors, but don't know how.
Thanks for your advice.
EDIT:
To make the things a bit clearer here is a sample of the code:
<cis:ChildWindow ... />
.
.
.
</cis:ChildWindow>
where cis:ChildWindow is derived from UserElement. Now the preview from VS can't create an instance of childWindow and throws an errror. If I build the Project everything is fine.
Does ChildWindow create objects (or have a DataContext) that require external assemblies, hardware drivers, or anything unusually picky?
If so, and if you can find out which object this is through trial and error, sometimes the following works:
bool inDesignMode = System.ComponentModel.DesignerProperties.GetIsInDesignMode(this);
if(!inDesignMode)
InitializePickyDriver();
It's worked for me a few times.
You can right-click on the file in Solution Explorer and choose to Exclude it from the solution. You'll then be able to build your solution and it won't complain about errors in that file.
But that only works if you don't need to use the file to build your solution. If you need the file to be included then I'm not aware of any way to achieve what you want, other than commenting out the lines that are causing a problem (other than the obvious solution, which is to fix the actual problem, but I'm guessing there's a good reason you can't do that).
I recently added a new project to my Visual Studio 2008 solution. Now, as I make edits in the new project, I receive a ton (~50) of type checking errors - indicating that an assembly reference may be missing. However, when I actually build the solution, the errors go away. As best I can tell, my dependencies are set and the build order is correct. What could be wrong?
It doesn't prevent me from building and deploying, but it's a major nuisance. It makes it hard to tell when I actually have introduced new errors (until I do compile). Thus, it erodes the usefulness of having the error window do static analysis.
Example, one of the 50 errors is this:
"The type of namespace name 'PersonManager' does not exist in the namespace 'Gideon' (are you missing an assembly reference?"
In reference to this line of code:
Gideon.PersonManager pm = new Gideon.PersonManager()
PersonManager is underlined in both places, and when I right click the type and selected 'find all references' I get an alert box that says "Cannot navigate to PersonManager"
However, the references are definitely there, because when I build, it works.
One other detail is that there is a mixture of C# and VB.net code, though I don't think that should make a difference.
Well, yes, the IntelliSense parser is not an exact replica of the C# compiler. It has a very different job to do, it needs to do something meaningful while the code is utterly broken since you are editing it. Tough assignment, they did a tremendous job with it. But as a side-effect, it can fail to parse things that are actually legal. It's quite rare but not unheard of, seen it myself a few times.
This won't go anywhere concrete until you at least give us some idea of what kind of errors you are seeing, along with a snippet of the code that generates them. You didn't do so, I can only recommend that you select another window so you don't have to look at them.
I had the same problem. I had a project in my solution that was causing the problem - I removed the project from the solution, then added a reference to that project in the main solution and the errors went away. Strange that it only happened on 1 machine. Opening the solution on another machine was fine...
I have been tracing a BAD_ACCESS error using NSZombieEnabled. As error I get returned:
*** -[MyDocument respondsToSelector:]: message sent to deallocated instance 0x2671b0
I do know what this means,however what surprises me is that I don't call this function anywhere, not in MyDocument.m nor in any imported files.To be exact, I don't call this at all in my whole project. The debugger will not go to the actual code that causes the error, but only shows the assembly code, which, when I click on it, gives me and even bigger list of not understandable numbers.
Does anyone have an idea where this weird "respondsToSelector" could come from? Maybe from frameworks I am using? I am really confused.
Thanks for any help!
respondsToSelector: is widely used in frameworks. For instance, if your class is a delegate or data source (highly likely for MyDocument) the delegating object will use it to determine which delegate methods you support.
In general, the way to find out where a problem like this is happening is to set a breakpoint on objc_exception_throw() (Run->Show->Breakpoints, double-click where it says “Double-Click for Symbol”, type objc_exception_throw) and run under the debugger (Build->Build and Debug - Breakpoints On).