Related
A couple of weeks ago I cleared the NuGet cache in Visual Studio... this broke everything for some time as it would not automatically restore all the NuGet packages for some reason.
After a lot of effort and manually restoring stuff, I have now got most projects in my (quite large) solution working, except one.
I am in the process of moving most of my code from .NETFramework projects, to .NETStandard and the websites to .NETCore, that in itself is a headache and may/may not be related to the problem, but I don't think so.
Anyway, this one project, which is a .NETFramework (4.7.2) web application and references many other projects in my solution, will not build properly.
Each time I build it, I get thousands of stupid errors from MSBuild, see the screenshot (ignore the top 4,they are genuine!). These are all errors which should be warnings, or ignored.
In the Project settings page I do NOT have "treat all warnings as errors" checked - in fact, in an effort to fix this, I have turned warnings off altogether as well.
The weird thing is, that if I build every individual project in the solution first, usually twice, and then build this one with out touching anything else, it then will build and launch in IIS (or publish)
So the site is actually working but something is wrong in MSBuild or VS that is breaking it.
I have tried running a Visual Studio repair, but that made no difference either.
EDIT also, it only does it on one PC, if I load the same solution onto my laptop, it will all build fine.
And from some of the errors, if seems that the you should change the Assembly Name of the SAM project to Sam. It is quite strange. Not sure whether you have install some extra Code Analysis extensions on your current PC but other PCs works well.
So please try the following steps:
Steps
1) disable any third party installed vs extensions under Extensions-->Manage Extensions-->Installed
It needs a restart.
2) run update-package -reinstall under Tools-->Nuget Package Manager-->Package Manager Console
3) close VS, delete .vs hidden folder under the solution folder, every bin and obj folder of the projects under the solution.
Besides, you could use devenv /safemode to start a initial VS without any third party tools to test whether the issue happens.
I have moved a Visual Studio 2010 project to another server by copying and pasting the folder contents into another folder on a different server.
My understand was that VS2010 handled this well; when I have done this locally it has never been an issue.
Now I get an error like this:
When I right click and "Reload project", the list of files briefly appears before disappearing again, giving the original error.
Am I doing something wrong?
I experienced the same problem today. Here is what I did and worked for me :
Open the .sln file.
Right click on the project folder and click Reload project.
You will see the projects and folders that you originally had.
You will see .xml publish file . Double click it .. You should be good to go now.
I had this problem today and it took me a while to figure out what was going on.
Your problem is most likely that your solution was originally made with a Visual Studio configuration that contained support for certain project types (such as "Windows Service" or some other exotic project type). The Visual Studio configuration you are using to import your solution does not have that support. In other words,
there is probably nothing wrong with your solution,
there is probably nothing wrong with your project,
there is probably nothing wrong with any of the files (as you mentioned they do display briefly, giving you a second of hope)
Just run the installer on the new Visual Studio and make sure the support is enabled for all the project types you need and try again.
In my case the problem was the .vbproj file had somehow been corrupted so the normal xml code was replaced with a long string of null characters. I noticed this thanks to a file that was generated in the same folder as the project file when I tried to open the project - it was called 'UpgradeLog.htm'. This had an entry saying ' Error on line 1. Expected '<' but found 'null character'.'.. suggests there may have been a recent update to Visual Studio that I hadn't noticed?
Luckily I could use my source control system to revert back to a slightly earlier version - I guess it shows how important it is to have backups!
In my case, I saw similar message (Projected was unloaded) and all I had to do was simply re-launching Visual Studio (2017) in Admin mode and the problem went away. Per one of the above answers, I tried to right-click and selected Reload but got a warning that, due to required access to IIS on the machine, I had to launch VS in Admin mode.
HTH
Found this answer and it worked for me.
Note:Sometimes, the path in File path property is grayed out and you are unable to get to the Browse button. In this case try deleting .suo files. Don’t worry, these files gets recreated when you rebuild the solution / project.
http://www.howtosolutions.net/2013/02/solving-project-file-error-could-not-find-part-of-the-path-with-visual-studio/
I had the same problem. I fix path to .csproj files in the .sln file with a text editor and now it is all ok.
Open Visual Studio as Administrator
I have a largeish solution in Visual Studio 2008 (around 30 projects, all C# and Script#), including some test projects.
When I start the application or run my tests, way to often Visual Studio rebuilds everything rather than just the changed parts and their dependencies.
If I don't change anything at all, it will not rebuild, but as soon as I change any file in any project, everything in the entire solution will be rebuilt, even the 90% of projects which were not affected at all.
Does anyone have an idea of what the problem can be, or provide me a hint of where I can start troubleshooting it?
Edit: To clarify, all projects in the solution are rebuilt, even those which are not directly or indirectly dependent on the project that has actually been modified. Even those which the modified project depends on, so it can't be a simple project reference issue.
The build sequence is determined by the project references (dependencies).
To avoid to build the projects depending on the project you've edited, you can use Build Current under the menu Build.
I setup CTL+B as shortcut to Build Current which saved me a lot of time than F6. Everytime I just use CTL+B after I save a file.
Hopefully this will help.
You can use the configuration manager to set up a specific config for your sln that will only build the projects you specify. You can find it under Build->Configuration Manager
I am debugging someone else's work and the solution is quite large. When I try to build the entire thing, several projects within the solution don't build and just skip. Viewing the output window during the build process says:
1>------ Skipped Rebuild All: Project: pr1lib ------
How can I determine why these builds were skipped? I am unable to find additional output.
This is with VS2008 and the solution is comprised of c# and c++ code.
Right click the solution, choose Properties and then Configuration Properties. Here you can choose which projects to build.
[edit]:
See Kdt's comment: ... when I looked in configuration properties ... the project build target was configured for "Mixed Platforms" while the solution was set to build "Any CPU".
*When this problem happened to me, The main project only had 'Any CPU' and it set the child dll to 'any CPU' too, however, I'd deleted that profile and left only 'x86'. Picking x86 for just the dll make it start working
[/edit]
Build, rebuild, and clean operations were being skipped. Unloading and reloading didn't help, and neither did restarting Visual Studio.
Once I removed the project from the solution and added it back, it is no longer skipped. To remove it, in Solution Explorer, right-click the project > Remove > OK. To add it back, in Solution Explorer, right-click the solution > Add > Existing Project and select your project
I just had the same problem- "unload project" and "reload project" solved the issue !
Restarting Visual Studio did the trick
If the confixguration is x64 and the x64 compiler isn't installed it will skip the project.
My solution is the same as mentioned previously: Delete -> Add existing project
But this solution implies that references between projects get gone
To avoid re-adding references: and in case if you use version-control system like GIT or TFS or whatever, it is possible to acheve goal with the following steps:
Make shure that all the changes are commited / checked-in before the operation
Go through all projects deletting them from solution and adding-existing them
Notice that the .sln file has changed
Keep the new .sln file, but undo the changes to all the .cspoj files with the version-control system
I had a weird one that may be worth documenting amongst the other possibilities here..
I'd added a Shared Project to my solution, with code that was used in two or three of the other projects. As you're aware - Shared Projects are just code, and not really a project in the traditional sense.. You can't 'build' a shared project, it's just code that is embedded into the other projects, and then built there.
But somehow my solution file had been updated as if the shared project was it's own thing that needed building. I'm guessing then that any time I was trying to build and I hadn't changed the code in the shared project, then it figured 'nothing has changed, skip those builds'
I found the shared project in the solution.sln file like:
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "Api.Common", "Api.Common\Api.Common.shproj", "{EC580471-D78A-4509-AC46-BD565553AD60}"
..which is fine. What isn't fine is that this project also appeared in the GlobalSection(ProjectConfigurationPlatforms) = postSolution like:
{EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Debug|Any CPU.Build.0 = Debug|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.ActiveCfg = Release|Any CPU
{EC580471-D78A-4509-AC46-BD565553AD60}.Release|Any CPU.Build.0 = Release|Any CPU
I removed those four lines from my .sln file, and now things seem happy again
The visual studio 2008 , it can be because 64 bit compiler wouldn't have installed.
Control Panel --> Programs and Features -> Microsoft Visual Studio 2008 professional --> [double click]
On Visual Studio Dialog
Next --> Add/ remove Features --> (Under) Visual C++ --> (select) x64 compiler and Tools
The first thing you need to do is diagnose why the build is skipping projects. So to get a detailed build output change the verbosity to detailed in the following place in Visual Studio.
Problem exists in VS 2010 as well; of the proposed solutions: editing build config, cleaning, changing/re-changing target framework, do NOT work. But unloading and reloading the project does.
I've just had this issue, and was able to resolve it by removing the hidden .vs folder in the topmost folder. After restarting Visual Studio everything worked again.
Hey, just fixed this one. Thought it might help. You most likely didn't install corresponding compilers along with the visual studio. This happened to me today - by default, VS 2008 installer doesn't install x64 C++ compiler.
If you have SP1, uninstall it before changing VS installation. When done, install SP1 again.
Close visual studio
Open the sln file with notepad
delete all of the things like this :
{B546C55D-9321-4FC0-B25C-46844222BEBE}.Debug with
Fakes|x86.ActiveCfg = Debug with Fakes|x86 (there will be a bunch of
them)
4.save the file
5.open visual studio and all better
Go to the build menu and choose "configuration manager". This will show which projects are configured to build in your selected configuration.
I had a similar thing just happen to me. I'm not sure what the problem was, but it would not Clean, Build, Rebuild, etc. I am operating in Visual Studio 2017 and wanted a netstandard2.0 assembly. The issue for me was that somehow the project type was incorrect, maybe I started from a netcoreapp class library, something like that, stuck in the Solution file, I do not recall. Anyway, I backed up the project, created a new netstandard class library project, and factored in the backed up bits, and that fixed it for me. HTH someone.
i updated to 15.9.11 , ... after some builds, same problem:most projects are skipped (which build a second ago without problems). Unloading/reloading the solution helps always in my case, but it will happen again soon.
I have no idea why... except a big bug in VS2017
I checked configuration manager , all checkmarks are set to build.
Maybe, it has something to do with nuget packages, but that is just a guess
The solution has only c++/vcxproj, no csproj. 64 and 32 are installed both
This happened to me in VS 2019, and the solution was to simply restart visual studio.
My build configuration was never modified.
I checked-in my project to source control from one computer and downloaded it to another and it will not build properly there. It will skip building projects and didn't even create the master \Debug folder for outputs.
The solution (VS2019) is to right click on solution and select Configuration Manager.
I saw the build checkbox was not checked for two projects that I was building (shown below). I don't know why they were unchecked but checking them and building project worked!
Right click on solution ->Remove then Add the existing project, this worked for me.
Had the same problem, found out that the project setting was for Itanium CPU, changing it to Intel fixed it.
Was running into the same problem with VS2005, all the configurations were correct .
It was even skipping the Clean project command.
Finally Unloading /Reloading did the magic.
Right click on Solution at at your solution explorer, then, click on Property at bottom of the menu. In the property windows, click on Configuration Properties -> Configuration on the left pane, you will see the list of projects on right pane, make sure Build check box is checked in the popup window.
If your solution contains a NuGet project (*.nuproj) file, try unloading it and then rebuilding your solution.
This worked for me after none of the above worked.
I had similar problem, I had one project which could not load in solution explorer due to some reason. When I loaded that project it worked like a charm.
I find that sometimes when you have target platform as set to lets say x86 in your solution and in your projects the project does not actually always had it selected.
To double check go to the project properties and see if you can select that platform in the Build->Platform setting if you can not then you will need to go to the configuration manager and create that configuration.
I had this problem with some Windows CE projects on a new PC. "Unload project" and "Reload project" appeared to fix the problem, but actually Visual Studio had simply switched to a different platform and built that.
It turned out that although my WinCE platform was shown as the active platform, Visual Studio didn't "really" see it. The solution was to reinstall the WinCE SDK with administrator priveleges:
Make sure Visual Studio 2008 is not running.
Open a “Visual Studio 2008 Command Prompt” as Administrator. On Windows 7 just right click the short cut and pick the “Run as administrator” option.
Enter the following command: msiexec /log SDKInstallLog.txt /package <the path to your .msi file>
When asked if you wish to do a custom or complete install pick custom, and instruct the installer to omit the installation of the documentation (this step was not necessary in my case; in fact I just asked it to "repair" the existing installation.)
Install
VS 2008 will skip x64 targets if you don't have the x64 compiler installed. VS 2008 does not by default. Kind of a duh, thing.
I had a very similar issue after generating a project from a decompiler from Telerik, then trying to recompile it. The project was skipped whenever I tried to rebuild it. Tried a lot of the suggestions above, but for me, it was the .NET Framework selected in the project properties.
Right-click project in solution file, select properties, application tab, change target framework from 4.0 to 3.5.
Then, rebuild, and I got a bunch of assembly reference missing errors, which makes sense since I haven't added references to them yet.
I update one small update of Visual Studio 2017 and then the installer reminds me to restart my computer,but I did not restart.When I build my project or solution in Visual Studio 2017,I meet the same above problem.I guess the update maybe the key,so I restart my computer,I did it.:>
I had this problem in Visual Studio 2017 15.9.4 and after some searching and putting some time I found out that in my solution the .csproj file of one of projects got corrupted after merging in TFS. (I could build other projects by unloading the problematic project from solution).
How I resolved my problem was that I compared the .csproj file before and after the merge and do fix that. And by fix I mean since my own project's type was .netStandard I removed unnecessary lines including Configuration PropertyGroup, all and others in the new .csproj file to make it similar to previous .netstandard-style version.
I am working in a Web Project in Visual Studio 2008. When I hit F12 (or right-click and select Go To Definition) Visual Studio is consistently going to the Metadata file instead of going to the source.
Some Points:
All the source code is C#, there is no VB.Net
All the projects are in the same solution
Everything is a project reference as opposed to a file reference (checked and double-checked)
I have tried the Clean/Rebuild Solution approach (even to the point of clearing out the Temp directory, Temporary ASP.NET Files directory, etc).
Has anyone else seen this behavior and/or know how to fix it?
Well, another developer found the answer. The specific project we had an issue with was originally added as a file reference, then removed and added as a Project Reference. Visual Studio however, kept both in the csproj file for the web site, causing the issue. He went in and manually edited the csproj file to remove the file reference to the problem project and all is fixed now
It happens when you don't add reference as a project but point to a dll or exe using Browse tab in Add Reference dialog. If you add reference using Projects tab you should go directly to the source code when you select Go To Definition.
However, if you install ReSharper, you'll go to source code even if you added your reference to a dll/exe using Browse tab.
Looks like it needs to be setup in Resharper as well. My Visual Studio does not navigate to .NET Framework source code until I enable it in Resharper.
1. close your solution.
2. delete hidden <name of the solution>.suo file in folder where your solution's <name of the solution>.sln file exists.
3. open your solution.
4. rebuild your solution.
For those using VS 2017 (I'm at version 15.3.4 at this moment) here are the simple steps:
Open your solution in Windows Explorer and close down Visual Studio
In the explorer menu, select View and ensure that the "Hidden items" checkbox is marked
Navigate to the subfolder .vs\[your solution name]\v15
Delete the .suo file
Restart VS and build your solution
That fixed it for me: F12 opened the actual source file, not the "from metadata" version.
Visual studio often suffer from a problem of going to metadata rather than your project if you shift location where you are building the project, ie you may have several versions to test things out.
Simply delete the reference and immediately add it back and everything will be sorted out.
The marked solution does not always work. You must make sure that the referenced project GUID in the project files is the correct GUID for the project you are trying to reference. Visual Studio does allow them to get out of synch in some circumstances. You can get the project GUID from the project file with a text editor.
So if project A reference project B. Open up project B.csproj in text editor, copy out project GUID from the tag. Then open up project A.csproj in text editor, and make sure that you are using the correct GUID. Search for project name "B" in this case. It should be at . Replace the GUID in the tag with the correct one. Save and reload.
Of course also make sure file based references to your projects are removed. You only want project references.
I've kill all VS instances, deleted the SUO, launch sln and it worked for me...
Remove the reference dll, Build (will get errors), ADD THE reference (you removed) then build again ... F12 on your function should then work (worked for me).
#1
Check "View - Object Browser" and if you see more than one assembly with the same name - that's why your getting this error.
For us it was a bug in VS 2019:
If you have ASP.NET "Razor helpers" in App_Code folder the Visual Studio 2019 interprets that as a different assembly but with the same name, that hides the actual assembly.
There's no fix for that other than rewrite those helpers to partial views or HTML helpers (you will have to do that anyway if you plan migrating to .NET Core).
See this workaround on MS's site and please upvote the bug there so MS fixes it
https://developercommunity.visualstudio.com/solutions/1008795/view.html (please upvote)
#2
Another reason why same assembly can be loaded twice in the object browser is if you have a unit-test project that starts iis-express process and never kills it properly.
I figured out how to solve my problem from this post, maybe it will also work for some of you.
I followed these steps:
Close the solution.
Delete the intellisense database file for the solution: .ncb
Open the solution.
Rebuild the solution.
(I believe either step 3 or 4 regenerates the intellisense database file when it is missing)
Intellisense, "go to defintion" and "find all references" should be working again.
In my case, (using Visual Studio Professional 2015), when I had disabled the XAML designer, the F12 stopped working.
As soon as I revert the changes, and restart Visual Studio, the F12 worked again.
Checked the pattern multiple times to confirm and then posted. Hope it helps someone.
Symptom:
Visual Studio 2010 Ultimate was repeatedly failing to find references to functions, #defines, includes, etc when using the "Go To Definition" or "Go To Declaration" or "Find All References" features - oddly Intellisense was working.
Fix:
Close Visual Studio
Delete (rename if you want to be conservative) the solution .sdf file
Reopen Visual Studio
The .sdf file will automatically be rebuilt by parsing the include files in your solution
For me, the GUID solution didn't work and I couldn't find my .ncb file. (Or maybe I'm lazy and didn't look hard enough, but that's not important.) Rebuilding and restarting visual studio didn't help either.
What I did was close visual studio and delete the .dll and .pdb being referenced in the top of the Meta Data file that my intellisense kept linking to. In my case it meant I deleted my .dll and it's .pdb file from Utilities/bin/Release. (Utilities is the name of the .dll project I was having issues with.) Then I restarted visual studio and rebuilt the .dll then the whole solution. No more problems!
Just found another cause. I upgraded my web project to 4.0 but left the class libraries at 2.0. At that point all the class libraries in my solution were treated as file references from my web project. Might help someone else...
I faced the same issue and one of colleagues gave me the following solution and it worked!
If none of the above works for you,
Remove all the references and add them back (make sure the path is
correct)
Go to Solution properties, and recheck the Project
Dependencies of all projects. Make sure the project that you'll be
using is added as a dependent in the project that you are working
on.
I did all suggested steps but nothing has been changed then
finally
right click and add reference menu, project tab
simply unselected the reference project.
save the solution.
select the same project.
Rebuild the solution.
Problem sorted. Hope this will help to some one.
Below steps worked for me.
Go to .csproj file
Open it in Notepad Go to line where dll is referred.<Reference Include="">
Delete the line
<SpecificVersion>False</SpecificVersion>
or
<SpecificVersion>True</SpecificVersion>
After deleting dll files from Visual Studio first and adding them back manually from Solution Explorer --> Website --> Add --> Reference and enabling 32-bit Applications in IIS fixed it for me.
VS2017 VB.Net Windows 10 Pro - I use an assembly names "SharedCollection" which includes a VB Module named MyGlobals. One of the globals is a FileVersion. References showed metadata and the Windows Service that referenced it had an outdated setting. I had tried some of the SUO remedies above and none of them worked.
This Worked
I deleted and recreated the project reference for ShareCollection in References.
click on web site menu from VS.
Add reference...
Click on project tab from dialog box
Select ddl
Click on ok button
In my case, I had just recently changed
<mvcBuildViews>
to "true" in my site's .csproj file (to find compile errors in my Razor view files: http://forums.asp.net/t/1909113.aspx?How+to+have+Visual+Studio+2012+returned+compile+errors+on+razor+syntax+error+in+asp+net+web+page+2+ ), and when I then built I was getting errors from my within my site's /obj/Debug/ directory. From any of those files (which were out-of-date), right-clicking and selecting "Go To Definition" would give me the [metadata] version.
So for me, none of the solutions here worked, because I wasn't starting from a file that was actually in my project. Deleted that entire /obj/Debug/ directory, the errors went away, and from any normal file I can correctly use Go To Definition.
I just ran into this problem on VS 2013. Something I could (did?) not isolate was changing the GUID in the CSPROJ file. Since the CSPROJ files are checked into SVN, I could not simply change the GUID on my local dev. Instead, I was constantly SVN reverting the local change each time it happened.
First, I had to solve the changing GUID problem.
Revert the CSPROJ to the checked-in version.
Open the CSPROJ via a text editor, NOT VS.
Extract value from the pristine CSPROJ file.
{B1234567-5123-4AAE-FE43-8465767788ED}
Open the SLN file via a text editor, NOT VS.
Locate the Project reference in the solution.
Project("{FAE12345-3210-1357-B3EB-00CA4F396F7C}") = "Some.Project", "....\assemblies\Some.Project\Some.Project.csproj", "{B7654321-5321-4AAE-FE3D-ED20900088ED}"
EndProject
The first GUID listed is the Solution GUID. For every project referenced in your SLN, you should see this value repeated at the first argument. The GUID following the .csproj is the one you want to replace with the pristine GUID.
This should solve the first problem, but the "Go to Definition" landing in meta data is not solved. In our SLN file, there is a master project (our web site), so its entry in the SLN file should contain a ProjectSection entry with multiple GUID values. Here is an example:
ProjectSection(ProjectDependencies) = postProject
{AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD} = {AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD}
EndProjectSection
Notice the missing GUID in this collection is the one from my pristine project.
Add the missing GUID as the last entry between ProjectSection and EndProjectSection. The format appears to be per-line, and it is {GUID} = {GUID}.
Save the file.
Open your solution.
Right-click a reference in the newly-added project and "Go to Definition."
I had a circular reference between the two projects involved (which is a no-no). Had to restructure my code a bit in order to solve it as both projects were truly dependant on each other. Removing one of the references solved the intellisense problem. It was logically flawed and I probably wouldn't have noticed without this error!
This one worked for me:
Right click the dll in the reference folder in your solution
explorer
Remove dll file
Right click the Reference folder, then
Add reference to the dll file again
This can happen if you're trying to jump to the definition in a project that has been unloaded (Unavailable). Right-click the unloaded project and select "Reload Project".
I modified the .csproj file and in the Reference -> HinPath changed obj to bin and it solved the problem.
I had a variation of this issue, where when I loaded my solution my referencing project had errors until I compiled the project it was referencing. At that point the errors disappeared but F12 took me to metadata.
The issue was a dependency in the project being referenced that conflicted with a dependency in the referencing project. I manually removed dependencies from the project being referenced until one of them resolved the errors in the referencing project. After that I was able to F12 to the actual code, and the project would load without errors.
If anyone knows exactly why this happens I'm interested to know in the comments.
This little trick solved it for me - unload the referencing project from the solution and then just reload it
Best guess is that you don't have debug information. Maybe you have multiple copies of your assembly on disk and it doesn't have the .pdb file with it.
Do a search for your assembly names from your projects and delete them all and rebuild.