I was developing an ASP.NET project and all went OK.
But now I'm getting errors, BUT everything in the code is OK.
I press F6 to compile all the solution, and I got errors everywhere. But the code is all OK (keep reading, you'll understand). Then I try to compile it again,again, again, again..... And in a tottaly random moment, i got sucess.
Then I try to view the page in browser. Compiling error!
Compile it again, Success.
Refresh the page, Compiling error!
Refresh the page again, Success!
And I didn't changed ANYTHING in the code.
And then I can keep programming normally, but when I close VS and open it again, this problem comes again.
Other things I try: deleting the bin folder and compiling again, rebuild the solution, build each project individually....nothing works.
Visual Studio is compiling "when he wants".
Why the hell this is happening?
Problem solved! I created a Handler with the same name, "Mensagem", and sometimes the compiler tried to compile the handler first, and sometimes, the Mensagem class first.
I just changed the Handler name, and its OK now.
That's incredible how these small errors can cause a great pain in the head.
Another thing I observed, i have a lot of classes, but only one class is returning false erros.
The main error is:
"Cannot implicitly convert type 'Entidades.Mensagem' to 'Mensagem'"
The class "Mensagem" is in the namespace "Entidades", that is referenced in the "using" section. When i try to code it, everything went OK, but when compiling, i got erros.
Its just this class.
Related
So I am wondering how come my IDE1100 is not working. I went to the only question related to this and it was about xamarin, Other Answer, I am not working with xamarin at all. I clicked on the error for more help it said I don't have F1 button workign but it was working then the issues said I didn't have the RazorAssembly.cs or Assembly.cs files were missing. Okay so I did what they told me to do n the link above but unloading and reloading that also did nothing for me. I then ran clean build again then ran a code analysis on the solution and I got all these weird code naming violations and I did not have the originally. It all started from trying to create a new migration because I was changing variable names. I figured well I don't need the database only one person in it and then bam just like that the issue reappeared. I have no clue of what I done to actually create this error. I don't want to restart the whole project again. I am using VS 2022 with MVC project.
So it turns out that it was me that messed up but it would not show my errors at all when I tried to build.
so I clicked on where my mouse is at in the picture and just clicked on the plus sign. It was initially build + intelisense but when I clicked build only it actually showed me an error that was easy to fix. I had to change the view names because I changed them. usually it would show me this error even in build + intelisense this never happened before like wth and you see the name stuff is gone too this is baffeling is this actually normal with vs 2022.
My Visual Studio 2010 debugger sometimes has a very strange behaviour...
Sometimes it doesn't stop at breakpoints, but when it stops, and I want to step into a method, the debugger just steps over it. Also the breakpoints in those over-stepped methods are ignored.
When this strange behaviour occurs, it also does not break on exceptions but simply ignores them.
I've tried to rebuild my project, reset the Visual Studio settings and disabled debugger settings like "Break only in my code", but nothing has worked.
How do I solve this problem?
Here are a couple of reasons and workarounds for why Visual Studio will avoid stepping into a particular method.
Just My Code is enabled. In certain circumstances the "Just My Code" setting will prevent you from stepping into a method / property. To avoid this you can disable "Just My Code" in the debugger options page (Tools -> Options -> Debugger -> Uncheck "Just My Code")
Symbols are not loaded for the target method. If the target method is a part of another DLL it's possible that symbols are not loaded for that DLL and hence Visual Studio will not be able to step into it by default. To force the symbols to load, open up the Modules view (Debugger -> Windows -> Modules), navigate to the DLL containing the method, right click and load symbols.
The method is explicitly marked with a debugger attribute such as DebuggerNonUserCode which causes the debugger to step over the method.
The method is actually a property or operator and you have "Step Over Properties and Operators" setting enabled (this is the default). This can be disabled via the debugger options dialog.
In my case it was "Step Over Properties and Operators" in Tools -> Options -> Debugger. Just had to uncheck that and after that everything was fine, I could step into.
Another source of confusion is iterator methods that use the yield return operator because they are rewritten by the C# compiler in such a way that stepping into them (F11) is kind of a "no-op".
You must wait for the iteration to occur to break into the method's code.
I've found the solution of the problem and it is really simple:
In my solution's build configuration, the "Build" check-box of the project where the methods are, that get over-stepped, was not checked. I checked it, and now everything works.
The most important thing to check is whether when trying to put a new breakpoint inside the method it refuses to step into, if the breakpoint is filled red liked the others, or half filled or has a special "look". If it does, hover over the breakpoint you created to find out why it isn't working.
If the breakpoint looks normal but still you can't seem to step into the method, try clearing the shadow copy cache: http://weblogs.asp.net/mreynolds/archive/2003/08/11/23576.aspx
Another thing to try is to make sure that you are indeed using the DLL you've just rebuilt by adding a MessageBox.Show (or something similar) to the method you can't seem to stop at, and make sure you get the box.
I struggled with this for a while. None of the answers given worked for me. I finally got it to work by doing the following:
Make sure the project is in debug mode (all projects)
From Windows go to a Command prompt and be sure to run as administrator
Navigate to c:\windows\syswow64\ (or folder where gacUtil.exe is located)
Run the following command (substitute path below to where your debug output version of the DLL is located.
gacutil /i "C:\Users\John\Documents\Visual Studio 2008\Projects\Project1\Project1\bin\Debug\MyAppDLL.dll"
You should get "Assembly successfully added to the cache"
Now run your project and you should be able to step into the DLL code.
WAG here, but I'd say you've referenced another project in your solution by BROWSING to a dll (project/bin/debug/mydll.dll) rather than by adding a "Project Reference." If you have multiple projects in your solution, remove ALL references to each project. Then, in the Add Reference dialog, hit the "add project reference" tab and select the project you wish to reference.
Project references are always updated on a new build. But if you, say, browse to bin/release and add a reference to a dll in that directory, when you switch to debug mode and add code and try to debug it, the old release version of the dll is loaded into the appdomain and VS won't be able to hit any breakpoints (you'll notice the breakpoints are empty circles and the tooltip will say something about the code not being loaded).
I have just found another reason for the problem, and a fix. I am creating a Windows Forms application using C++ in Visual Studio 2010. I am using the FreeType library and some code which depends on it and for various reasons this code has to be compiled with 'No Common Language Runtime Support' selected (Properties -> Configuration Properties -> General). I was not able to get breakpoints to be hit in this non-CLR code.
The fix is that the main app must be compiled with 'Common Language Runtime Support (/clr)', NOT 'Pure MSIL Common Language Runtime Support) (/clr:pure)'. That immediately solved the problem. I can now debug into, and hit breakpoints in, the non-CLR code, including the FreeType C code.
I have experienced the same recently. Not sure what I did exactly though. Try to physically clean up your solution, i.e. delete all bin directories from all projects of the solution. That usually helps to solve a lot of problems.
Try disabling "Require source file to be exactly matched" option in tools->options->debugging->general.
My solution was to create a new project and load all my .vb files into the new project. Solved all of my issues.
My problem was simple. I have multiple projects in the solution and I just need to set the project I am working with as Set As Startup Project.
I have a web project running in Visual Studio 2010 and target .Net framework 4. When I 'Build' the solution it will tell me the build was successful even though there are (known) errors in the code. If I open a page that has an error, the compiler will then pick up on the error and underline it in blue instead of red.
Is there a setting that would drive this kind of behavior? Any ideas on how to fix?
If you have multiple projects in your solution it is possible that one of them is not set to build. In your build output window did you see the name of the web project you are having issues with?
Also, check the build configuration manager to make sure you have it set.
If it's an MVC app, the view files (*.as{p,c}x) will not be compiled unless you explicitly enable it by passing /p:MvcBuildViews=true or enabling that flag in the project file for a given configuration.
I'm having similar (if not identical) problems with compiling an ASP.net 4.0 WebForm. I have a page that is a copy of an existing page in terms of markup, but the code-behind has not been created. As an example, the markup has an ASP:Button with a click event, but the event handler has not been declared in the codebehind yet. When I do a full Build/Rebuild/Clean etc., no errors are found. I open the page, and a compiler error is thrown. As far as I know I haven't made any changes to settings anywhere, just started doing this recently. Additionally, it appears that my break points aren't being caught anymore either. I'm not sure if the two are related, but they did start happening around the same time.
Wondering if anyone has a solution to this 2010 bug. I have a project that built fine in Visual Studio 2008 that wont build in 2010 because Visual Studio is holding on to the dll after the application is run ONLY if a designer window is open. I created a really light weight project that shows this problem. If you create an application then create a lib dll. Put one form in the dll, open the form in design view and then run the application. It will run fine, then close the app, go to the code view of the form in design view, and change the code ( I just renamed a single variable) then try to recompile you get the following:
Error 1 Unable to copy file "obj\Debug\customlib.dll" to "build\debug\customlib.dll". The process cannot access the file 'build\debug\Customlib.dll' because it is being used by another process.
If you run Process Explorer and search for the dll, the only process holding the dll is devenv.exe!!!
I have done a ton of searching on this problem and have found similar issues with older versions of Dev Studio where people were able to just add a pre-step to move the locked dll to another name (.locked) and build. Well that works the first time, but the next time you run then edit you are locked out of both the current dll and the one you moved to .locked, so unless I am willing to add code to randomly generate a name for the locked dll, this wont work for me (I don't want my debug directory size to grow with files never getting deleted.)
I have only found one workaround and if you are in this same boat this is what I have to do to edit and run. I make sure EVERY design view window is closed BEFORE I ever run my project in the debugger. If you close all the open design view windows devenv.exe will not hold the dll.
Does anyone have a better solution to this problem?
I'm not sure whether this will work for you or not, but this similar question if you have this line in AssemblyInfo.cs:
[assembly: AssemblyVersion("2.0.*")]
changing it to:
[assembly: AssemblyVersion("2.0.0.0")]
will solve this isue.
The Visual Studio add-on "VSCommands" claims to have a fix for this problem. I've not tested it yet, but it also claims to have an in-IDE stackoverflow reputation tracker which intrigues me :)
Your "Close designer before debugging" workaround seems to be working for me (so far), for which I'm very grateful. It was beginning to get to the stage where am large part of my day was spent in the following workflow...
F5
loud expletive
ALT F4
WIN 3
waits impatiently...
F5
I have had the same problems for a long time and then suddenly they disappeared. I realized that the source of the problems was initializing code in the constructors of WCF services and WPF controls. After cleaning the constructors from any dependencies to other assemblies everything has been fine.
So my suggestion is: Clean your constructors.
In WPF it is possible that inserting:
if (DesignerProperties.GetIsInDesignMode(this)) return;
or similar will have the same effect.
OK, this is my own fault, but I can't seem to rescue myself.
Whenever I try to step into a class that has fields with assignments calling into .NET code, I get a dialog box that contains the text "There is no source code available for the current location.":
For instance, stepping into the constructor of the following class would give me the above message:
public class Test
{
private Stack<String> _Dummy = new Stack<String>();
public Test() { }
}
I assume this is because at some point I fiddled with the settings for the symbol server, but no matter what I fiddle with now, I can't seem to get rid of that message.
Where has my stupidity forgotten what it did?
Summary of my current options:
[ ] Enable address-level debugging
[x] Enable Just My Code (Managed Only)
[ ] Enable .NET framework source stepping
[ ] Enable source server support
Symbol file .pdb locations - empty
Cache symbols from symbol servers to this directory: C:\temp (empty)
See if some source files are accidentally excluded. Do properties of the solution and look at the Debug Source Files section under Common Properties.
In Solution Explorer, check your solution property page under Common Properties, Debug Source Files. If you see the assembly listed under "Do not look for these source files:", delete it and the issue should go away.
Open the solution property page
Check "Do not look for these source files"
If you do not want to debug .NET assembly, a quick fix to avoid "No source available to current location" problem is to uncheck "Require source files to exactly match the original version" check-box under Tool -> Options -> Debugging -> General
Here's what I did to solve this problem. First, stop debugging and just have your solution open in VS. Next, make sure your solution config is set to Debug as opposed to Release. Then simply do a Rebuild (not Build, Rebuild). The next time you fire up the debugger, it should function as normal and you shouldn't get that error message.
Hope this helps!
If you don't want this annoying tab to appear, you can try this add-on that I created:
http://erwinmayer.com/labs/visual-studio-2010-extension-disable-no-source-available-tab/
It is directly downloadable on the Visual Studio Gallery:
http://visualstudiogallery.msdn.microsoft.com/en-us/fdbb2036-471e-40a7-b20e-31f8fd5578fa
Check if your projects have a project reference, not a DLL reference! If there exists a DLL reference, your changes will not be recognized by your referenced project, and you will get an error message like yours.
This error made me go crazy as well. I was using 'AjaxControlToolkit' and had referenced it using 'Add Reference' to my project.
I deleted the 'AjaxControlToolkit' reference and added the same with 'Add Existing Item' and after that I had no problems at all...
I had the same problem in an unmanaged C++ program: when debugger was in main function it always showed "No source code available" and, what was interesting, other functions in this file was shown without problems. In this case, the problem was that I allocated too much data on the stack. After reducing it, the debugger started to work without problems.
It was in Visual Studio 2010.
One way, that also works for Express Editions of Visual Studio (say, Visual Basic 2005 Express Edition), is to rename the .suo file. It is in the same folder as the solution file, .sln. Exit Visual Studio before renaming the file.
The .suo file contains non-critical settings, like window positions, etc. However, it also contains all the breakpoints which is why it is probably better to rename it than delete it in case this action is regretted.
This is how I solved it.
Right click your project -> Properties - > Compile -> Advanced Compile Options...
Then Set 'Generate debug info' to 'Full' from the drop down menu.
Hope that helps.
This worked for me:
Check the "Enable Unmanaged Code Debugging" on the properties page for the referenced *.DLL
Recompile referenced *.DLL
Remove and then re-add the referenced *.DLL to your project
Have you tried to build that page? I had an issue with something similar with AjaxControlToolkit: Modal Popup Extender. It did not show until I gave it CSS and ASP.NET controls.
I had for some reason disabled all the Common Language Runtime Exceptions in VS 2017.
To fix this, open the Exception Settings under Debug > Windows > Exception Settings and mark the checkbox Common Language Runtime Exceptions in the Exception Settings window
I had the same issue, It showed me that the error is on AjaxControlToolkit, but the problem was in my HTML syntax, especially in a div tag, I was putting only the close tag '' without the opening tag
I ran into this problem because of difference between framework versions of test projects and main projects. When upgrading main projects frameworks version, be sure to not forget to upgrade test projects.
I had this problem in VS 2017 C++
TLDR: It was accesing data beyond the limit
The program finished in debug mode and it showed this message: wntdll.pdb not loaded
After fixing it with this answer it started to show the message: There is no source code available for the current location
But also there was a message that popped saying: app.exe has triggered a breakpoint, but the breakpoint was not in my source code, it was in the source code generated by VS in debug mode, Right click in the source code -> Go to Disassembly and the break point was int 3 instruction
At the end it was just a stack overflow, since the code was accesing data beyond the limit, I just fixed the code and the messages were gone
I guess VS didn't show an error about accesing data outside the limit because I was using Winapi function GetEnvironmentStrings() and in the site says: Treat this memory as read-only; do not modify it directly and I was modifying it :)
I had the same problem, and I solved it on this way (Visual Studio 2008):
"Formato de la informacion de depuracion" to "Base de datos de programa (/Zi)"