i just switched from vs2010 to vs2012, and installed t4mvc. now. all my links are stop working.
return RedirectToAction(MVC.Admin.Food.AdminAdded());
I will get cannot resolve symbol MVC.
#Links.Content.images.btn_save_changes_png
I will get cannot resolve symbol Links.
i have no idea how to fix it, pleaes help me, thank you.
Can you make sure that T4MVC is generating its files? Try right clicking the .tt file and choosing 'Run Custom Tool', which should force the generation.
If the files are generated, you should be able to look at them to make sense of why they don't match your references.
try clearing the VS caches and update to the latest build of ReSharper.
the caches are located at
C:\Documents and Settings\Administrator\Local Settings\Temp\VWDWebCache
and possibly here
C:\Documents and Settings\Administrator\Local Settings\Application Data\Microsoft\WebsiteCache
REF:How do you clear your Visual Studio cache on Windows Vista?
Below are listed some helpful links:
MVC 3 Project Upgrade Tool
May be its a KNOWN ISSUE which has been RESOLVED
Related
The problem
Suddenly, Visual Studio (2015 RC) started throwing error CS7069 in my face a lot. It states
Reference to type '...' claims it is defined in '<assembly>', but it could not be found.
Yet VS's functionality "Goto reference" did function and squigglies weren't consistently present, so I figured something weird was going on.
How I created the problem
It started when I was refactoring/splitting a project. I was moving .cs files from one project to a new one. Types that I moved to the new project couldn't be found anymore by the compilation process of a project that referenced both projects.
What I tried
I verified that the relevant assembly was indeed referenced, present and had the type with public modifier. I rebuilt it, checked version numbers (of target frameworks etc), removed the relevant reference and re-added it, cleaned solutions and projects, checked configuration manager settings, removed all VS's temporary files and whatnot, and I couldn't fix the bug for 4 days. 4 long days, might I add.
Googling didn't result in anything either, so I hope that the next poor fellow who made the same mistake as I did finds this page, as I finally found out what was going on:
I had two projects with identical assembly names...
Renaming the new assembly in its properties menu made all errors vanish.
Fixed bug on Visual Studio 2015.
Go to Tools menu, Options, Debugging, General: Check: "Use the legacy C# and VB expression evaluators"
Try to clean/rebuild the project. It helped me.
Also try to remove all of the *.suo and *.user files in your solution folder
http://blog.galasoft.ch/posts/2014/01/quick-tip-what-to-do-when-visual-studio-freaks-out-and-everything-is-red/
I had this problem and it turned out I had the wrong build configuration selected. The reference projects and the project I was building were not selected for that build configuration. Simple to fix, but not something I looked at for a while.
Can any one tell me why this type of error message is prompting when i am creating new project.
The error message is as below.
" Could not load file or assembly .
'Microsoft.VisualStudio.ManagedInterfaces, Version=8.0.0.0, Culture=neutral,PublicKey Token=b03f5f7f11d50a3a' or one of its dependencies.
The system cannot find the file specified."
What should I do to overcome this?
Maybe the "Repair" option on then VS2010 Setup will help. If not you might have to do a complete uninstall/reboot/install cycle.
A quick google search gave me something pointing at the VS SDK - maybe a reinstall of this might help too.
I had same issue after installation SP1. I tried re-install of SP1 with no success.
Get the Microsoft.VisualStudio.ManagedInterfaces.dll(if it is not present in your environment you can download it from here ) and install to global cache. Restart VS2010 and load you project again.
Why do I get the following error when building a setup project?
An error occurred while validating. HRESULT = '80004005'
One project in solution had ToolsVersion="4.0" (in .csproj file), changed it to ToolsVersion="3.5" and setup project builds fine.
Both of the reasons I found are already in other answers, but they are in separate answers and not fully explained. So, hopefully this will combine the possibilities and give good means of debugging each. :)
Common Reason
My problem was not a dependency error. However, that does seem to be the common reason. So, basically, you need to check your MSI file and make sure that all dependencies are still valid. Probably the best blog response on how you can easily resolve this if it is a dependency issue is An error occurred while validating. HRESULT = '80004005'.
Extract from blog:
Follow steps below to troubleshoot.
If you have multiple project outputs in your solution, identify the project that is giving the problem. You can do that by removing one project at a time from the Setup Project(S) until error goes away.
Once project is identified, identify the reference that could be giving the problem.
Check if the project(A) is referencing to a project that has been removed from solution. - Remove such references if any.
Check if the Project(A) is referencing to a project that was moved to a diffenrent physical location after it was added as a reference. - Remove and add such references.
Rebuild setup project after fixing the reference accordingly to see if error goes away.
Alternative Reason
My problem had to do with Visual Studio versioning, however. So, if your dependencies are valid and you still are getting this problem, then you resolve this if it is a problem with VS2010 .
Basically, if you run MSBuild and see this warning:
Project file contains ToolsVersion="4.0", which is not supported by
this version of MSBuild. Treating the project as if it had
ToolsVersion="3.5"
Then the problem is Visual Studio versioning. This means that one project was opened or created in Visual Studio 2010 and then saved or added to an existing 3.5 solution. I simply searched all files in my project for ToolsVersion="4.0" and found the offending .csproj file, opened it in a text editor and manually changed the 4.0 to a 3.5.
This error is related to a dependency error. I removed all references to my primary output project and added them again. It now compiles OK!
I ran up against this issue today. The solution in my case? Restart Visual Studio 2008.
In my case my solution (VS2008) had a project that was also referenced from another solution (VS2010). In the VS2010 solution I had upgraded the project to .NET 4.0. When I later realized the project was also used in another solution I downgraded it to .NET 3.5. For some reason everything seemed to be changed correctly in the csproj file except one place which is mentioned here: Error in setup project HRESULT = '80004005'
I know this is already solved somewhere else but I wanted to shed some light on this from another problem angle.
While simply removing and re-adding the project dependencies will work in many cases, it is important to note that:
The error message "An error occurred while validating. HRESULT=80004005."
usually happens when project is referenced to the other project which is
not added into the currect [sic] solution. Setup project only supports
dependency projects within same solution.1
I have spent enormous time on this one myself, though none of the above worked. But I have found another solution with a registry hack, you need to add a new DWORD (EnableOutOfProcBuild) value of (0) to HKCU\SOFTWARE\Microsoft\VisualStudio\14.0_Config\MSBuild\EnableOutOfProcBuild
Note: this is for Visual Studio 2015
In my case I had installed Visual Studio 2010 alongside Visual Studio 2008. My setup project, when opened in Visual Studio 2008 gave the same error, but was OK in Visual Studio 2010.
If copied to another machine that did not have Visual Studio 2010, but did have Visual Studio 2008, then it would compile.
I installed Visual Studio 2010 and converted the solutions to that version. Because of performance issues I changed my solutions back to Visual Studio 2008. Everything was better now but I got an error when I tried to compile the setup project. I realized that I had a Visual Studio 2010 Test Project in my solution so all I had to do was unload the Test Project and Build the setup project again.
Summary: unload any Visual Studio 2010 project in solution.
I hope it helps.
I know this is kinda old news, but my particular issue and solution are not specifically stated here (as far as I can tell - if I missed it, I apologize).
I had same problem. It would not compile my project, but had no errors. All I could see was "Build Failed". I opened up the "Output" file (Click View--> Output on menu), and it told me exactly which reference (in my case a .dll) was causing the problem.
I deleted and recreated the reference and it changed the reference name from Microsoft.Office.Core (which was appearently only a 32 bit version) to "OFFICE". Then everything worked great. -- Make sure to make a note of the path to the file you are referencing in the properties window... My new path was exactly the same, but the reference name changed anyway.... still scratching my head on that one...
So the moral of the story is... When you get no errors and your build fails, check the "Output" tab and it might help.
I read this answer from another post on Stack Overflow, and it has worked for me.
Open your setup project file (.vdproj) in Notepad (or any other text editor). Delete these lines at a beginning of the .vdproj file:
"SccProjectName" = "8:"
"SccLocalPath" = "8:"
"SccAuxPath" = "8:"
"SccProvider" = "8:"
Build again - the error is gone. That error didn't stop me from deploying, building, debugging (or anyting) my project; it just annoyed me. And it came on even if I set all projects to be build in a current configuration and the setup project not to.
This assembly is in the GAC: Microsoft.SqlServer.Management.RegisteredServers.dll
How can I add a reference to this assembly in Visual Studio?
I can view the file in c:\windows\assembly\
As the others said, most of the time you won't want to do that because it doesn't copy the assembly to your project and it won't deploy with your project. However, if you're like me, and trying to add a reference that all target machines have in their GAC but it's not a .NET Framework assembly:
Open the windows Run dialog (Windows Key + r)
Type C:\Windows\assembly\gac_msil. This is some sort of weird hack that lets you browse your GAC. You can only get to it through the run dialog. Hopefully my spreading this info doesn't eventually cause Microsoft to patch it and block it. (Too paranoid? :P)
Find your assembly and copy its path from the address bar.
Open the Add Reference dialog in Visual Studio and choose the Browse tab.
Paste in the path to your GAC assembly.
I don't know if there's an easier way, but I haven't found it. I also frequently use step 1-3 to place .pdb files with their GAC assemblies to make sure they're not lost when I later need to use Remote Debugger.
Registering assmblies into the GAC does not then place a reference to the assembly in the add references dialog. You still need to reference the assembly by path for your project, the main difference being you do not need to use the copy local option, your app will find it at runtime.
In this particular case, you just need to reference your assembly by path (browse) or if you really want to have it in the add reference dialog there is a registry setting where you can add additional paths.
Note, if you ship your app to someone who does not have this assembly installed you will need to ship it, and in this case you really need to use the SharedManagementObjects.msi redistributable.
I've created a tool which is completely free, that will help you to achieve your goal. Muse VSReferences will allow you to add a Global Assembly Cache reference to the project from Add GAC Reference menu item.
Hope this helps Muse VSExtensions
In VS2010, from the Add Rerences window you can click 'Browse' and navigate to C:\Windows\Assembly and add references to the assemblies that you want. Please note that the files may be grouped under different folders like GAC, GAC_32, GAC_64, GAC_MSIL etc.
In VS, right click your project, select "Add Reference...", and you will see all the namespaces that exist in your GAC. Choose Microsoft.SqlServer.Management.RegisteredServers and click OK, and you should be good to go
EDIT:
That is the way you want to do this most of the time. However, after a bit of poking around I found this issue on MS Connect. MS says it is a known deployment issue, and they don't have a work around. The guy says if he copies the dll from the GAC folder and drops it in his bin, it works.
The only way that worked for me, is by copying the dll into your desktop or something, add reference to it, then delete the dll from your desktop.
Visual Studio will refresh itself, and will finally reference the dll from the GAC on itself.
Assuming you alredy tried to "Add Reference..." as explained above and did not succeed, you can have a look here. They say you have to meet some prerequisites:
- .NET 3.5 SP1
- Windows Installer 4.5
EDIT: According to this post it is a known issue.
And this could be the solution you're looking for :)
May be it's too late to answer, but i found a very simple way to do this(without a hack).
Put your dll in GAC (for 3.5 Drag Drop inside "C:\Windows\assembly\")
GoTo Projects --> Properties
Click Reference Path (for 3.5 it's "C:\Windows\assembly\")
and Build
Hope it helps
The relevant files and references can be found here:
http://msdn.microsoft.com/en-us/library/cc283981.aspx
Note the links off it about implementation/etc.
I found this extension for VS 2013 Vitevic GAC Reference.
Issue: Just started today, all references to any assembly outside of the solution fail to resolve, with The referenced component 'SomeComponent' could not be found. when trying to build. This happens for both 3rd party components (all 15 or so of them) as well as all .NET Framework assemblies - basically anything that isn't another project in the same solution.
Trying to load some other solutions produced the same issue. Creating a new WinForms project worked without a problem, however. (Scratch that, it worked before reinstalling VS, now that doesn't work either. I created a new WinForms app as well as a WPF app, and the designer can't load the assemblies either. I tried targetting 3.5 and 2.0 and no luck.)
Things I've tried:
Repair Visual Studio installation
Rebooting computer
Started VS with /resetsettings flag
System Restore to 2 days ago when it was known to be working
Uninstalling VS and reinstalling
Fresh checkout from SVN
Does anyone have any experience with this and know of a way to get this working again? My strongest Google-fu has failed me, so I'm asking here. Can mark community wiki if requested.
Update:
I tried "upgrading" Windows (to the same version) since I didn't see a repair option for Vista and it's still a no-go. I reinstalled everything that seemed relevant. So far, it's looking like I'm just gonna have to back up and reformat I guess unless a solution comes up sometime before tomorrow.
Update2:
I just backed up data and reformatted, so I'm no longer able to verify any ideas that I haven't tried yet, so I'll just leave the bounty to expire on its own to the top voted answer and as a reference to anyone else who may have this problem later.
I had the same problem. It turns out that something was wrong with NuGet. I removed the following part of the *.csproj-File (opened in a text editor). This has solved the issue for me:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
In my case, the solution was completely different. It looked like it was an issue with NuGet paths (caused by my moving the project to a different solution and then back again.
I edited the .csproj and removed all references to NuGet and associated packages. I also removed the packages folder from the solution folder.
The system components then magically reappeared.
Suggested next debug step: review Project Designer: References -> Reference Paths to verify that the paths to your system and third-party components appear correctly. (Watch out for things that can slip past the old Mark I Eyeball like drive letters.)
Try running VS after turing on Assembly load logging with fuslogvw. You'll be able to see additional errors captured by the runtime when it tries to locate and load the assemblies.
In Vista, you'll have to run fuslogvw as an administrator and somtimes specify an explicit path to save the logs.
You can also try debugging Visual Studio by attaching to it from another instance, or with the basic debugger included with the .NET SDK.
I had this similar issue not too long ago.
I found that the issue was caused by git not properly creating .exe's when jumping from branch to branch(we have nuget.exe in a path and it was getting deleted/added when jumping branches). When you would try to run nuget, windows would throw a fit over the exe.
After reseting the branch many times, I finaly got the exe to run properly. Then I noticed that the security on all the directories in the repo had been reset, so I had to deal with that.
After all of that, visual studio then started to play nice.
Hoped this helps someone!
It may also be a problem with references of other projects in the same solution. I only wanted to build one project, but got this message about references in another project. Although the problem in the other project was correct, I think the message was not correct:
I did not expect the message about another project (the other project was no dependency, so it did not 'need' to be built)
I could not 'interpret' it, because it did not mention the project it was about).
Well, if you click on the error, in VS 2012 RC, and then debug it, the error is gone...
I know that this is an old question but it is still happening in the latest version of Visual Studio (2015). I fixed it in a different way that might not have been available back when the question was asked. Basically, it is related to the fact that VS can't find the .Net Library package. To fix in the latest version of Visual Studio (2015):
Right Click on your solution in the Solution Manager. Choose "Manage NuGet Packages for Solution..."
in the NuGet Window, go to "Installed".
If you have something related to Microsoft.Net such as "Microsoft.NetCore.UniversalWindowsPlatform", remember the name and uninstall the package.
Now go to the browse tab and find the package and install it again. Don't forget to select the correct needed project.
Everything should be ok now.
I hope this helps somebody!
I hate to say it, but it sounds like the system is pretty borked. There has to be a point when it is quicker to reinstall the OS than it is to continue trying to fix the current install.
I just hope you take this in the right spirit... sorry.
Shot in the dark here, but I've run into the same (similar) problem. The issue I ran into was related to having a 64bit machine and running a project that had a mixture of 64bit and 32bit 3rd party dll's. The solution was to ensure I had the correct bits (32v64) and then to have the project build in 32 bit mode: project properties > build > platform target: x86.
Another time this occurred I had to remove all the 64bit dll's and reinstall with the 32bit dll's
HTH's
.nuget folder was missing. add the .nuget folder with nuget files (usually 3 files). open the solution and no warnings on references. My submodule has nuget references and when I pulled the latest version, the solution needs .nuget folder in the project folder.
i.e.
project
/.nuget
/submodule
/.nuget
Visual Studio was unable to find any of my references.
What i did, and following some solutions above, was:
Right click solution entry in Solution Manager window;
In the newly opened NuGet window go to installed, select all entries and update.
The problem gets solved!
Check your output with ILDASM to make sure the references are showing up correctly -- compare them to an assembly that works, and see if anything jumps out at you.
I once encountered a problem, which is in the *.csproj file. It defines an Error node in the Target node, that if one reference/nuget-library doesn't exist, it throws the error while building. The problem is VS do not show correct status for other libraries, thus all the referenced libraries looks like non-loaded, that the local file path cannot be found in the property window.
Here is a sample.
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. xxx.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
<Error Condition="!Exists('..\packages\NOT-Exist.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\NOT-Exist.targets'))" />
</Target>
...