Working on a C# MVC project, I can have multiple files open in Visual Studio. When I press F5 to start debugging, the debugging starts if the currently open file is:
a controller (*.cs);
a model (*.cs);
a stylesheet (*.css);
a config file (*.config);
a partial view (*.cshtml)
However, if the open file is a View (*.cshtml), the browser opens with the "Server Error - URL not found" page.
Additional info: The solution has always been under source control with SVN but at some point, the repository location changed and from then on (I think), this strange error occurs. It didn't happen before, I could debug without thinking if a view file was open or not. The change wasn't performed by me and I lack details on it. I am not sure these things are related either.
Anyone has come across a similar issue? How to solve it?
I am guessing the problem is your project setup. Do following:
Project right click -> Properties -> Web -> Start action
Most likely it has "Current page" checked, which does not play well with ASP.NET MVC view, it just tries to open the view directly, and not via route. Every other type of file you mentioned is not detected as page, and thus VS does not try to open them as such.
You might want to choose a "Specific URL" there, or just make a habit of switching to a different file before hitting F5.
i created a little application (win forms) thats create a solution, adds a project and some files to the project. By clicking a button, the new solution should open by the installed vs2010 express. Thats works fine, everything is ok. My question, is there a way to open a specific file in the solution when the hole solution was loaded? For a better understanding, the user (of my application) creates a sln with 3 files (a.cs, b.cs and c.cs). He selects b.cs (in my application), and opens the sln. In the editor in vs, the preselected b.cs should be open.
I've tried to create a sou - file, but i think thats not the right way...
Is there a way to do this?!
Thx and regards
Sascha
Visual Studio remembers the files you had open when you last closed the solution, along with other things like breakpoints, by using the SUO file. You can check this with a simple experiment: close your solution with just a single file opened inside it (a.cs, for example), manually delete the SUO file (don't worry, VS recreates it if it doesn't exists) and when you open the solution again you'll see you won't have any file opened, and you'd lost any breakpoints you had.
So the obvious thing to do here would be to manipulate the SUO, storing on it the file selected by the user and then opening VS from your tool. The only thing I've found on the documentation is the IVsPersistSolutionOpts but I don't have any direct experience with it.
Also check this CodeProject article: while its main focus is to add a Tool Window to Visual Studio, it also uses IVsPersistSolutionOpts.
I've got an app that uses our DAL and when I run it in debug mode (vs2010) and purposely try to make the app crash (for instance, leave the connection string empty of the DAL), vs2010 opens the code for the DAL at the point in which it crashed. Which is ok, but I'm then able to edit that .cs file and save changes, which I don't want. I've verified this by having the DAL project opened in another instance of vs2010 and when I make the app crash and change the DAL.cs in the app and save it, the DAL in vs2010 tells me that the file has been modified outside the project and asks if I want to reload it.
How can I prevent this from happening? The only reference I am using to DAL in my app is the reference to the DLL, that's all.
The AssemblyName.pdb file links the compiled DLL to the original source.
Visual Studio uses this file to display the source code when debugging.
You can delete this file and get rid of the source link.
This will give you a vastly inferior debugging experience.
Have you tried going to "Tools > Options > Debugging > Edit and Continue" and unchecking "Enable Edit and Continue"?
Make the .cs file(s) read-only. If its read-only, you'll be able to see it, but you won't be able to save changes. (Depending on your Visual Studio settings, you might still be able to edit the file in memory, but that seems irrelevant, since the changes you make won't be persisted to disk.)
If you need more fine-grained control (like where you want to be able to edit the source files, but not your testers), you can use access control lists (ACLs). Ask more questions about that on Server Fault.
Yes, you could disable debugging or turn off the generation of PDB files, but that makes it very difficult to debug the code, which is probably the reason why you're purposely trying to make the app crash.
I am opening files from a server ASP.net and the VB codebehind files, and my visual studio is not working correctly, Intellisense is dead and if i right click the "Go to defenition" option is disabled. These files are not part of a solution.
This is strange though because it was working properly yesterday. If I create a new project the intellisense works great, yet opening this single file it fails.
I have tried to re enable intellisense by resetting visual studio, I tried editing the text editor settings so that Auto list members and Parameter information are both checked. I even tried installing ReSharper and nothing worked. I have rebooted twice and even tried copying the file to a local drive to work on yet nothing.
Does anyone know why this is happening and what I could do to solve the problem? Im working on a rather complex problem and intellisense would make it a lot easier.
I managed to fix this problem which manifested itself after my ReSharper trial expired.
Steps to fix are:
Tools/Import and Export Settings
Reset all settings
Back up your config
Select your environment settings and finish
Intellisense started working again straight away.
For me simply hitting Ctrl+Alt+Space to re-enable Autocompletion fixed it.
I had the same problem. It only affected one of my solutions. Others seemed fine.
To correct it I deleted the solution's user options file (.suo).
When I opened the solution again, intellisense was working.
For the benefit of searchers, Nicks suggestion is good, but if you don't want to reset all your settings, you could follow the recommendation in this post.
It states - "go to "Tools | Options | Text Editor | C# | General and check the "Auto list members" and "Parameter information" checkboxes"
I should first note that upgrading my RAM from 4 to 16GB seems to have made this issue go away.
Here's the steps I go through:
If only one file/window appears to be affected, close/reopen that file. If that doesn't work, try below.
In Visual Studio:
Click Tools->Options->Text Editor->All Languages->General
Uncheck "Auto list members"
Uncheck "Parameter information"
Check "Auto list members" (yes, the one you just unchecked)
Check "Parameter information" (again, the one you just unchecked)
Click OK
If this doesn't work, here's a few more steps to try:
Close all VS documents and reopen
If still not working, close/reopen solution
If still not working, restart VS.
For C++ projects:
MSDN has a few things to try: MSDN suggestions
The corrupt .ncb file seems a likely culprit.
From MSDN:
Close the solution.
Delete the .ncb file.
Reopen the solution. (This creates a new .ncb file.)
Sometimes, it could be because of different extension style that you are using for the files.
In my case Intellisense is working in all the files except for a file in a different project of the same solution.
When I have changed the extension of the file to cxx from cpp,it started working.
The includes and other files in the solution are of extension .cxx or .txx.
Thank you
Save your solution. Closing the VS2010 instance for this solution and re-oprning worked for me.
Here I assume that Intellisense was working OK but stopped for some unknown reason without changing any default settings.
Prabhdeep
After uninstalling ReSharper, the squigglies that show up underneath a syntax error stopped showing up in the code editor.
This blog post helped me fix the issue.
Try this:
Close any open instances of visual studio, delete the folder 10.0 inside `C:\Users[username]\AppData\Roaming\Microsoft\VisualStudio\' and restart the visual studio. Issue will be fixed.
In my case, none of the above worked (although I discovered that sometimes the *.suo file is the trouble maker - in those cases deleting it helps).
I fixed it successfully the following way: Let's assume your solution has the name MySolution. Do the following:
Reset the settings (as described here). Close Visual Studio 2012.
Locate the file MySolution.sln.DotSettings (it is in the same folder as your MySolution.sln file)
Rename or delete it (for example rename it to XMySolution.sln.DotSettingsX so VS won't read it)
Open your solution by double-clicking on the MySolution.sln file
And afterwards Intellisense was working again just fine. I assume the file MySolution.sln.DotSettings got corrupted.
Note: The file MySolution.sln.DotSettings was created and checked in to TFS by a team colleague who had installed ReSharper. The issue occurred on a different PC without ReSharper where the same project was opened.
For me, this was related to an incorrect xaml file build action in an Azure WorkerRole project (bizarre, though it may seem!). Please see my entry in this post if you want to know more:
C# VS2010 Entering break mode failed
The fix for the error in the above thread also resulted in the intellisense starting to work again.
I fixed this problem by removing Sybase Power Designer VS extension.
You can try to disable other extensions.
Exactly the same issue, though would appear only on certain projects (even within a single solution).
Removing the *.*proj.user file (e.g. *.csproj.user) for the projects in question properly reset the missing features ("Go To Definition", "Organize Usings", Intellisense on certain types, etc).
In our case, I suspect this happens sometimes when we switch branches with an SCM that uses a single working directory (like git). If setup properly, it wouldn't track *.user* files but that means that if there are incompatible changes in it across different branches, you need to regenerate it.
So of course the "sometimes" would depend on the current branch and the next branch.
Unfortunately I don't see a very good solution if that's the case. Sometimes you really want to keep the user settings across branches if they're compatible, sometimes you want to regenerate them unconditionally. Ideally, you might even want to only change parts of them when switching, while keeping other parts.
If you never need to keep them and are fine with regenerating them every time, then you can configure your SCM to always remove these files while switching branches (e.g. using hooks for git). This is a pretty naive solution however, doing it more universally correctly would require a smarter system (aware of the semantics behind the .user files and capable of capturing/prompting user intent when needed).
save, close and reopen the source file you are working on. This works every time for me.
Try to add the statement:
<%# Page Language="vb" AutoEventWireup="false" CodeBehind="Default.aspx.vb" Inherits="IP_Updater.Default" %>
...at beginning of your page. The above example is applied for page Default.aspx written in VB.NET.
This is the problem related to Microsoft MSDN , your MSDN might be getting some problem. The solutions to this is uninstall MSDN and then re-install . before going for this make sure that you system is free from virus attack.
Hope that after doing , the Microsoft Intellisense will start running
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.