I'm using my own Extension Methods throughout several of my projects. When I compile(Build/Rebuild) all is fine. However when I start the debugger and the code recompiles, I get a list of errors all associated with the extension methods stating that they aren't a member of the class they are attached to. Any thoughts on why this might be happening? It seems intermittent as I can recompile and clean and recompile several times and it finally will allow me to launch the debugger.
Possibly the PDB's are not being generated properly? Are you launching from VS or attaching to a process? If attaching, make sure the PDB's are in the same location as the application.
Try:
Project Properties -> Build -> Advanced
Set 'Debug Info' = Full
Also, what namespace do you have the extension methods in? Make sure they are in the ROOT namespace or just remove the namespace all together (just for now as a test).
What kind of types are you extended? Is it possible you have two types of the same name and you're trying to extend the wrong one?
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 have a problem with COCOS2D_DEBUG. CCAssert() and CCLOG() is enabled in the classes I created but not inside any cocos2dx classes. I see my logs in debug console but logs of cocos2dx is not displaying even if I traced them using step-in, step-out, etc.
I added new scheme to my project so I can switch provisioning profile easily. I added COCOS2D_DEBUG = 1 on that scheme in Preprocessor Macros in Build Settings. I have it all setup and it is working except for the problem in CCAssert() and CCLOG().
I have no idea why they are not working. I need them specially CCAssert() to prevent any wrong code that I am doing. I need to enable them since I'm in a team project.
I am using the new scheme that I created. I notice in cocos2dx.xcodeproj > Build Settings > Preprocessor Macros, there are only Debug and Release. Do I need to add also my scheme in cocos2dx.xcodeproj?
Try using CClog() instead of CCLOG()
Yes i have faced this issue before.You need to use CCLog instead of CCLOG
I've been rather confused by some SGEN stuff. I've enable the generation of serialization assemblies for one of my projects. Originally I got the follow error which I believe I've solved by doing some caspol stuff on a remote assembly.
Unable to load one or more of the request types. Retrieve the
LoaderExceptions propery for more information
Now however, I don't get an assembly generated. Adding some debugging/verbose output provides the message "SS.dll does not contain any types that can be serialized using XmlSerializer". I've read that this is because of a proxy switch applied by VS. The odd thing is it doesn't seem to be a problem with any other project.
So if I disable the proxy switch (example here) it seems to work. The linked build events however seem to do all projects. I don't know enough about MSBuild to tweak to just a single project, does anyone know what I need to change?
Additionally, if this change is made, is there a way I can automatically include this in a installer (VDProj)? I can't statically link to the SS.XmlSerializers.dll because the each dev uses a custom path.
Discovered the following post which talks about adding the <SGenUseProxyTypes>Off</SGenUseProxyTypes> to the csproj file which seems to work :)
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 to make all my public variables variables/methods/classes internal when compiling my Visual Studio project. The source code would not change but when the compiled library is done, it should only have internal access. Is this possible?
I have "InternalsVisibleTo("ClassLibrary") " set inthe Assembly info file for all the projects, however, I would not like to run a replace all on "public " to "internal ". Does anyone know if there is away around this? So when I compile, build my project, the release project is only allowing internal access.
Thank you and have a nice day,
Joe
I think you have misunderstood the use of the InternalsVisibleTo attribute. It is used to allow code in another assembly to access types and members declared as internal.
Say you have AssemblyA, in which you have internal class SomeClass. Then you have AssemblyB. The code in AssemblyB cannot use SomeClass, since it is internal in AssemblyA. You can then, in AssemblyA, use InternalsVisibleTo to grant access for AssemblyB to use the internal types and members of AssemblyA.
If you simply want to make the code internal to AssemblyA, you will need to declare the types accordingly from the start; there are no shortcuts for that.