I tried to create an ASP.Net website using F#, .Net-Core 3, Ionide, and Visual Studio Code however, when I tried to set a breakpoint in an F# file it didn't get hit.
But when I put an
assert false
In front of my breakpoint, I get the exception, and the breakpoint gets hit afterward.
I have also tried the same in Visual Studio where the assert correctly breaks, but when continuing, it doesn't hit the breakpoint, even though VS Code does.
In VS Code, this doesn't work:
let x = 4 // <- Breakpoint
But this does:
assert false
let x = 4 // <- Breakpoint
I also get this warning when starting regardless of whether I add the assert or not.
Breakpoint warning: No executable code of the debugger’s target code type is associated with this line.
Possible causes include: conditional compilation, compiler optimizations, or the target architecture of this line is not supported by the current debugger code type.
What could be the cause, and how could I fix it?
In the end, the problem was the complex inter-project dependencies I had.
ASP.Net Project (F#)
Migration and DbContext Project (C#)
Unit-Test Project (F#)
DbContext ASP.Net shared objects Project (F#)
I solved the problem by keeping the Migration Project but moving the DbContext into the ASP.Net Project. So instead of a reference from the Migrations to the ASP.Net Project, I changed it to the other way around. That also allowed me to move the shared objects to the ASP.Net project and delete the Shared Object Project.
So this is what it looked like afterward
ASP.Net and DbContext Project (F#)
Migrations Project (C#)
Unit-Test Project (F#)
Although I didn't do it to solve this problem, it solved it as a side-effect.
I hope this will help someone else when they experience the same or similar problem.
Related
I try do debug a blazor webassembly app, that references a shared project named Test.Shared. I've been trying to set breakpoints in that projects code but nothing helped - breakpoints just aren't hit.
When I'm trying to set a breakpoint outside in the calling code and then step into "Test.Shared" source - it just seems to go step by step through the underlying code (I have to hit "step forward" multiple times before it proceeds the debugging to the next line, and the number of hits changes when I reduce/increase the number of lines in the underlying method code) but its not displayed in the debugger window.
So, after some investigation, I figured out that I can make the debugger work when I throw away all the code from the Test.Shared and leave only one simple test static method. Based on this fact I guess there is some specific type of C# code that causes the whole containing library to be invalid for debugging.
Any suggestions what this code type might be?
The environment I use:
Visual Studio Enterprise 2019 16.6.2
NET Standard 2.1 as a target platform for both Blazor app and shared library
NET Core 3.1 as a target platform for the hosting web app that serves webassembly app packages
Microsoft.Components.WebAssembly 3.2.0
The issue is with having attributes that have enum values inside of them.
Many people are having this problem and it's better explained in Blazor Wasm: debugging broken when referencing #attribute with enum contructor argument #25380 by zbecknell:
Here's a simple repro project: https://github.com/zbecknell/Undebuggable.
See Counter.razor:4 for the line that breaks debugging for the project:
#* The following line breaks debugging for the project, no matter how long you wait *#
#attribute [BadAttribute(BadEnum.Default)]
So I'm a lucky boy, I've been tasked with upgrading the development environment but not the code of a monster classic ASP product. It has been developed over several years and contains huge amounts of superfluous code in.
In order to modernise the development environment I'm targeting the IDE and moving away from FrontPage (yes, I know!); I've created an empty .Net project in VS2015 Community edition, manually added the legacy classic ASP code.
The advantage is by using VSnn it can be linked into TFS seamlessly and allow proper SDLC process to be enforced.
The problem is, I cannot attach a process in order to debug because the legacy code does not compile when I Build -> Build Solution. As I understand it the solution must build in order for the break points to be enabled?
There are 4 error types repeated hundreds of times during build;
Statement cannot appear outside a method body
Identifier expected
Declaration expected
End If must be preceded by a matching If
My questions are, how can I debug this beast if it will not compile?
Is it possible to ignore these warnings for a successful compile?
Is it possible to add break points and hit them in VS2015 for script only debugging?
And yes, I would burn this beast to the ground and use .Net but its not an option.
Something doesn't add up here. Classic ASP files aren't compiled, they are evaluated at runtime. I created a test project with both a WebForms page and Classic ASP page. Both worked by default. I attempted to reproduce your scenario by removing an opening if block but didn't receive any compile errors or warnings.
I am using VS2015 but would suspect to see the same since at least VS2012 if not early versions.
I have a problem similar to VS2010 always thinks project is out of date but nothing has changed (I'm also on VS 2010):
I Enabled C++ project system logging which told me that:
00000727 29.93245506 [5864] Project 'C:\foo.vcxproj'
not up to date because 'C:\foo\INTEROP\INTEROP.bar.1.0.DLL'
was modified at 01/22/2014 11:02:49,
which is newer than 'C:\foo\RELEASE\METAGEN.WRITE.1.TLOG'
which was modified at 01/22/2014 16:02:30.
This is apparently telling me that foo project must be rebuilt because either bar.dll or the interop have changed.
foo is a C++/CLI project.
bar is a COM DLL.
foo has bar.dll as one of it's references.
I haven't rebuilt bar.dll (date for the dll file is yesterday).
I haven't modified any settings in project foo (to affect interop).
My question is: Why is Visual Studio deciding the interop is out of date and triggering a re-build on every single run of the application?
Note: This is a web application. foo is directly referenced from the web. bar is not directly referenced by the web.
EDIT:
I've created a simple look-alike solution with just 4 projects (2 for COM, website, and C++/CLI assembly). It seems the C++/CLI assembly always updates the INTEROP.bar.*.DLL file every time any build is triggered. This doesn't seem to be the case in the solution having problems.
This was my mis-understanding: I thought the interop DLL should only be updated if 1) the reference is re-added. 2) The COM object being referenced (possibly just the API) changed.
Apparently, interop.dll is updated every build of caller.
Finally this wording is extremely confusing to me and seems incorrect:
A was modified at 11:02:49, which is newer than B which was modified
at 16:02:30.
How could something from 11:02 be "newer than" something from 16:02? (almost feels like a backwards >= / <= check)
PS - I'm not adding the example solution here, because it doesn't fail like the real solution does.
Sorry for the confusion. It looks like I was leaving out one level of indirection in the dependencies. The chain was: ASP.NET Website -> C++/CLI Assembly -> COM DLL -> C/C++ Native DLL. All in a single solution.
We ended up refactoring to move all the COM DLL code into the C++/CLI Assembly changing it to merely: Web -> C++/CLI Assembly -> C/C++ Native DLL. At this point the problem went away.
It's not a very satisfying answer, but I don't have enough spare cycles to really dig into it now that it's no longer causing trouble.
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'm using VS 2008 Developer Edition and am finding some bugs with the Test Projects.
I am getting one error that doesn't make sense - I have a class called 'Foo' which I need to test and created the blank test class automatically.
Foo takes 3 paremeters in its constructor - IBar, IBaz, IBang.
When I write a test case, I will Dim foo as New Foo(bar,baz,bang), and I will sometimes get an error that says = 'Type IBang could not be implicitly converted to IBang'. This error does not make any sense.
Even more odd - if I switch to an instance of Foo_Accessor() instead, the error goes away. I've played with the references and then I can eventually fix the above error - but then I get the same error for my Foo_Accessor() class!
I clean, rebuild, and sometimes the error will go away - but then I get the error 'Foo_Accessor' is not defined. Now I go to the Foo class and do 'create accessor' again - again, it still gives the same error. So at this point I'm stuck and my solution won't compile, and the only thing I did was add a new test case through visual studio!
Has anyone seen these issues and could please help?
Also - I have tried everything, including instructions from MS such as - renaming the type, re-referencing the project / in different ways, unloading the projects, etc, etc.. still I wind up with either the 'ifoo cannot convert to ifoo' bug or Foo_Accessor is not defined bug... I'm about to just break down and give the damned property I have to check a ReadOnly accessor... !
It's hard to say for certain but it sounds like you have a problem with your references being setup incorrectly. What's likely happening here is that one of the references between your projects is setup as a DLL reference vs. a project reference. This can confuse the type system into thinking that Bang from the project and Bang from the DLL are actually different types.
I would delete all references between my projects. Then go add all of them back again being careful to select the project from the project tab of the add reference dialog vs. the Browse one. This should fix your problem.
Is this a multi-language project or just a single language project? I've found this type of problem is more likely to occur in a multi-language project but it's certainly happened in a single language one.