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).
Related
I'm trying to port my console app over to a Blazor app. Everything worked fine inside the console type project, but it's not inside the Blazor project so I'm trying to troubleshoot. The app calls some things from a separate "class library" type project within the same solution.
The troubleshooting process itself is having issues of its own though. After a little bit of confusion I realized that the breakpoints set inside the referenced class library type project's code are not being hit.
Checking to console, I see it gives the error:
L: Unable to insert breakpoint at FtxApi.FtxWebSocketApi/<Test>d__5:MoveNext ():15
Is there anything I need to do (project settings or something) for the debugger to hit these? Or is it not supported at the moment?
Right now I'm just using a lot of Console.Writeline sort of as a workaround/replacement. And I noticed that the Console.Writelines inside the referenced class library type project are being called.. but only up to a certain method call that comes from a third party package. Execution seems to return from that point (nothing is called after it). Not sure what's going wrong there - more troubleshooting is needed, which brings us back to the breakpoints not firing (ideally I'd be able to make use of them).
I understand Blazor is new (and I'm an absolute beginner at using it), so not everything needs or is going to be perfect. I'm asking about the breakpoints kind of out of curiosity (I'd like to get them working but no big deal otherwise).
What I'd really like some insight into is: What might be going on with the code seemingly stopping execution / returning at that one particular method call? The method I'm calling is WebSocket.Open(), from the package WebSocket4Net. As mentioned above, I've tested this before (in a Console app) and it worked fine, so I'm guessing it's somehow related to Blazor which I'm unfamiliar with. I'm unsure how to get any more info to help debug this problem. Any help appreciated.
Edit:
I managed to find a solution to my problem without the use of debugging tools like breakpoints and such (I just used Console.Writeline a lot). I guess Blazor does not support some websocket implementations or something, because I found this error: System.PlatformNotSupportedException: Operation is not supported on this platform. blazor.webassembly.js:1 at System.Net.Sockets.Socket coming from websocket.Open(). I managed to get it working by implementing System.Net.Websockets instead, similar to this. Though my troubleshooting is over (for now), I'm still wondering if it's somehow possible to use breakpoints inside other referenced projects.
There are 2 solutions:
Solution 1: Right-click at Solution, choose Properties, choose Common Properties, Choose Multiple startup project, choose Action Start for Foo.Client, Foo.Server, Foo.Shared . Something like this
See https://blog.magnetismsolutions.com/blog/paulnieuwelaar/2015/04/07/debug-multiple-projects-at-the-same-time-in-visual-studio
Solution 2: Compile SharedProject, attacht PDB for debugging.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-an-executable-not-part-of-a-visual-studio-solution?view=vs-2019
I'm pretty sure this is a bug in the VB6 IDE but I haven't found any definitive reference to it before...
Sometimes when I've loaded a project which has some dependency issue (missing reference, etc.) the IDE will show an error like this:
("Compile error: Can't find project or library")
Note the text which it highlighted is a call to the UCase$ function which is essentially built into the language. There's no way its library is actually missing.
Is this a known bug? Is there any rhyme or reason to the text which is selected when this happens?
Update: The standard libraries which include things like UCase() are included so that is not the actual problem. The highlight really seems to be nonsensical.
VB can do some strange things, but... check both the content and order of your References. UCase$() isn't 'built into the language' in the way you might think -- it's not in the VB runtime, but in the VBA runtime, which must be included as a reference.
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 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...
We have just switched to vs2010 from vs2008, and our projects compile and run well without any problem. However, the xaml designer has some errors. Here is one of the errors hope someone can provide a solution.
We have a custom MarkupExtension, and we use it in xaml to get certain resources. Something like this:
<Button Style="{l:GetResource Key=MyButtonStyle}" />
I know we can use StaticResource or DynamicResource. However we have our reasons to use the custom markupextension.
The error message from the designer is:
'GetResourceExtension' is not valid for Setter.Value. The only
supported MarkupExtension types are DynamicResourceExtension and
BindingBase or derived types.
My question is that the code works fine in vs2008, and also runs fine in 2010, how to make the 2010 designer work?
I've written a few Markup Extensions and although the code runs I get Xaml Error's like the one you get all the time. Assuming you have valid code I found the only way to get rid of the errors was via the rebuild option and then running the app.
Of course the problem is if you change it again or move it the errors seem to come back. My assumption is the static compile cannot fully resolve whatever your markup is doing and is throwing the error based on this.
In my case I was writing a method binder and because the object was null until runtime I ended up having to use new Object(); and swapping it out at runtime. It's hacky but the compile error were driving me nuts.
The xaml parser seems to be better in 2012 but even then there are the odd errors.