Related
I have a project in windows application than was in VS2008. Now I convert it to VS2010. When I want to run my project, I get this message:
"This application has failed to start because the application configuration is incorrect. Review the manifest file for possible error."
How to I can run my application?
Thanks.
I had the same problem where my entire C# solution was created in previous version and it did not work in new VS.Net version giving the same error. Here are a few things that will help you resolve the problem
Expand the References Item and check if any item has a warning symbol attached to it.
If (1) , click on References->Add Reference and try to add the reference which has the warning. Now the warning sign has to go away.
If the references displayed in 'Add reference' dialog box is grayed, you should probably get the reason by hovering next to the reference.
For me it was grayed and it clearly mentioned that the component is not compatible with the current .NET Target runtime. Right click on Project -> 'Properties' and try to change the .NET Runtime and give a shot by compiling the entire solution and try to execute it.
If it still fails , try looking at eventviewer logs by going to Start->Run->Eventvwr
This should be a good way to debug this problem.
Honestly...I deleted the App.config file and Re-build. And started working.
Without understanding what was going on, I was able to fix this issue for a Windows Forms project I had just converted from VS.Net 2008 to 2010.
After conversion the Target Framework was still .Net Framework 2. When I changed it to 4.0, my application could be started and debugged.
In then noticed a new line in app.config:
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
So, just for the sake of interest, I changed the Target Framework back to 2.0 and the line changed to:
<startup><supportedRuntime version="v2.0.50727"/></startup>
The application would still run.
Then, I removed the new line altogether and the application would still run!
Finally, I undid all my changes and started the conversion again. Now, the application would run immediately!
So, if you run into this issue, just try these steps and see if it helps you.
Check discussion here:
http://social.msdn.microsoft.com/forums/en-US/vbgeneral/thread/e60dcbf9-c6a0-47a6-bc37-68d4edc45276
In my case the reason for this error was an invalid app.config. R# renamed the root element from <configuration> to something else (probably because there was another variable that I renamed with the same name).
I found this by following Gopalakrishnan SA'S advice to look in the Event Viewer where I found:
Activation context generation failed for "my.exe".Error in manifest or policy file "my.exe.Config" on line 3. The application config file root element must be configuration.
In my case, I forgot just a simple note,
in the requestedPrivileges you should place one requestedExecutionLevel, NOT MORE
I checked the event viewer to find the error "The application config file root element must be configuration".
It turns out it was the namespace referenced in the app.config.
I had opened it in VS 2015 after it being created in VS 2008
.NET 4, console application. The project is set to 'Debug' mode. The breakpoint being set is in the primary/startup project. I have right-clicked -> Clean, and right-clicked -> rebuild, both on the Solution and project levels.
Following the instructions in this SO question, I have confirmed that my "Build and Run" options are set to 'prompt' for both 'When projects are out of date' and 'when build or deployment errors occur', and I am NOT getting a prompt when I F5 to build/run.
Also, the 'save all changes' under 'before building' is also selected (plus I manually saved them myself).
I monitored the output window of the application, see this line:
'MyApplication.exe': (Managed (v4.0.30319)): Loaded 'C:\exepath' Symbols Loaded.
I restarted the VS2010 instance. I restarted all open VS2010 instances (of other projects). I've even gone through a reboot.
However, the breakpoint I am setting in the startup project is a hollow-red circle, with the notice that 'This breakpoint will not currently be hit, The source code is different from the original', and, in fact, is never hit.
So, this is really 2 questions:
1) How do I fix this problem so I can properly breakpoint
2) When I see this, does that mean my code is executing from an older build?
I've had this problem once myself but that was on a vsto addin. In that case there were left over intermediate files under the users/appdata directories that were actually loaded instead of my app.
There is this blog article that has a whole load of possible reasons for this error and then a whole bunch more in the comments from other users
This can also happen if you have a solution with multiple projects, and have the wrong project selected as your startup project in VS2010 and VS2012.
Now, obviously, I wouldn't expect debugging to work if I have the wrong startup project selected -- the debugger is attaching itself to the wrong process!
But this error message (in my case) was terribly misleading. It made me think something else was wrong. I tried a bunch of solutions in this thread (nuking various /bin and output directories) when really it was something very simple (wrong startup process).
If you are using vb, check that you are building the project for the active solution configuration (Build, Configuration Manager..., Column under Build is checked. Also check the project properties, Compile tab, Advanced Compile Options, and Generate debug info is set to Full. Sorry I can't tell you where this may be in C#.
The only other time I've seen this is when two projects in the solution are referencing the same dll but they are referencing from different sources. One from a project reference and another from a file reference for example. If the "copy local" option is true, there would be the potential of overwriting the dll with an older version of the same dll.
My solution might help people who have signed the assembly.
After lot of head scratching for the past two days, I was able to resolve the same issue by doing the following simple steps:
Go to your Visual Studio project properties.
Go to the "Signing" tab.
Uncheck "Delay sign only" option if it is checked.
Now run your project and it should work.For me it did work.
In my case was this same problem (“The breakpoint will not currently be hit. The source code is different from the original version.”) caused by fact, that I tried add breakpoint to declaration:
DateTime dt;
bool b = DateTime.TryParse(null, out dt);
(first line of code)
So I assume that message is "universal" and may have many different causes.
This can happen if your system clock was changed since the last compile. Your PDB file will be different date than the one your are trying to debug. Delete the PDB files in the project and recompile.
I experienced the problem when Project > Properties > Web did not have "Enable Edit and Continue" selected. After enabling this feature the issue was corrected.
It is important to note that under Tools > Options > Debugging > Edit and Continue "Enable Edit and Continue" was selected, but it was not enabled for this project.
Just go to Tools / Import and Export Settings
Choose reset all settings then click Next
No, just resetl settings, ovewriting my current settings then click next
Choose your current language, por example C#. then click Finish
If you have multiple solutions open, try simply closing all Visual Studio instances and restarting only the instance you need.
In my experience this has happened when two branches of nearly identical code are open in different instances.
doing a "clean solution" from VS Build Menu might help you.
I had to go over all those steps to fix the issue on my computer.
Make sure that debug = "true" on your web.config
Clean and rebuild all projects
Delete every file inside the bin folder of all projects
Close and open Visual Studio, rebuild, and run the project again.
Go to your solution folder -> obj -> Debug - > delete the .dll file and build the solution again.
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.
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)"
Every few days VS2008 decides to get mad at me and fails to generate a designer file claiming it cannot find the file specified and that it's missing an assembly. Here's the scenario:
The aspx page has a reference to a custom user control (inheriting UserControl) which references another assembly in the backend. There are many other references to this "missing" assembly in other places in code which don't throw errors. rebuilding, updating the source to the clean copy, shouting at the computer, punching the screen, etc all fail to work.
Any suggestions? This is quite annoying.
We've had similar problems before, unfortunately I don't remember the exact solution.
If your using a "Web Site" project (no project file) then start by checking that both your page and your control both set the ClassName property in the first line of your aspx/ascx file and that you specify the full name of the class including the namespace.
Example:
<#Control Language="VB" AutoEventWireup="false"
ClassName="YourProjectName.YourUserControl"
Inherits="YourProjectName.YourUserControl"
CodeFile="YourUserControl.ascx.vb"
%>
Many times not setting all of these will still work but you will get odd compiler errors and behavior in VS.
If you using a Web Site Application project try deleting the designer file manually and then right click on your project and choose "Convert from Web Application." This will should recreate the designer file for you.
My only other suggestion would be to recreate the page and/or the user control from scratch.
Jared, you've hit it. Using "Convert to Web Application" to manually generate the designer file solves my problem. I'm glad you posted this before i started reinstalling. Thanks.
You might try archiving a template of a new file with its designer equivalent. If VS coughs then you can do an "Add Existing" option with the file you already have.
It seems, however, to be an issue with your installation of VS2008 so you might try reinstalling it.
I found that using a custom control, you would need to add a reference to the .dll. This fixed it for me after migrating from a web site to web app.