I had been happily coding along on a decent sized solution (just over 13k LOC, 5 projects) which utilizes Linq to Sql for it's data access. All of sudden I performed a normal build and I received a sweet, sweet ambiguous message:
Error 1 Build failed due to validation errors in C:\xxx\xxx.dbml. Open the file and resolve the issues in the Error List, then try rebuilding the project. C:\xxx\xxx.dbml
I had not touched my data access layer for weeks and no adjustments had been made to the DBML file. I tried plenty of foolhardy tricks like re-creating the layout file, making copies and re-adding the existing files back to the project after restarting Visual Studio (in case of some file-level corruption); all to no avail.
I forgot to wear my Visual Studio Skills +5 talismans, so I began searching around and the only answer that I found which made sense was to reset my packages because Visual Studio was not loading an assembly correctly. After running "devenv.exe /resetskippkgs" I was, in fact, able to add the dbml file back to the DAL project and rebuild the solution.
I’m glad it’s fixed, but I would rather also gain a deeper understand from this experience. Does anyone know how or why this happens in Visual Studio 2008?
New Edit: 10/30/2008
THIS WAS NOT SOMETHING THAT JUST HAPPENED TO ME.
Rich Strahl recently wrote on his "web log" about the same experience. He links to another blog with the same issue and used the same action.
I have encountered this issue a few times since this original post as well, making me think that this is not some random issue. If anyone finds the definitive answer please post.
After installing Phalanger for Visual Studio 2008, I attempted to create a new PHP WinForms Application. The project creation failed with a similar error message, stating that a DLL required could not be loaded (Failed to load file or assembly...). Running the devenv.exe /resetskippkgs command in Visual Studio 2008 Command Promtp resolved the issue immediately.
Thanks for the info.
I also get this error when trying to compile the data access layer in the second solution (installer). What I do is that I run Custom Tool on the dbml-file, and this does it.
There is really no errors in the dbml file that needs to be corrected.
My theory in this is that Visual Studio caches the compiled version of the dbml file, and that the cache is invalid for other solutions. I guess running /resetskippkgs does the same thing as recompiling the dbml file.
Anyway, there are no fix for this yet?
TBH, I have had a couple of instances like this where files "seemed to go crazy".. However, upon investigation it has appeared that the files have changed in some way, shape or form.. (e.g. sometimes changes can be made to the file by inadvertantly changing a property somewhere that seems unrelated).
I think there are too many possible issues that could really cause this, and based on the fact that the problem has been resovled, it seems like an answer will not be found..
I had the same issue in VS 2010 (build failed due to validation errors in dbml file). I resolved this by viewing the designer view of the dbml file and dragging a table slightly to a different location so that it refreshed the dbml layout etc files. This seemed to do the trick, but was a bit of a weird issue.
Related
I've had a problem with my Windows 7 after an update, neither Safe Mode nor Recovery Mode could resolve the problem. I was forced to reinstall Windows completely. To develop on my projects I need Visual Studio 2010.
I always had ReSharper installed and got used to its features, so I installed it aswell.
Everything setup I tried building my solution but encountered a problem ...
(The underlined file can be found here: https://up.zone/aj)
After hours of trying to resolve the problems, I figgured out that ReSharper was the problem. I can build the solution perfectly fine without ReSharper installed. Having it installed, even if all features are turned off and the services are suspended, causes these errors in the picture above to show on build.
I managed to resolve two out of three errors by following the instructions of this Reddit user on his post: https://up.zone/ag
Now I am left with one more exception I cannot figgure out how to resolve. I couldn't really find anything helpful googling, which means you guys are my last hope. I really do not want to go back to developing without ReSharper.
This is the one:
Any idea?
Thank you!
Update 1
I figgured out that the problem must be in the NuGet.targets file, located in the .nuget folder in our solution.
I managed to find a workaround following the suggestion of this post, I am now able to build the solution without any errors.
To summarize, remove this line out of your *.csproj file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Although this works, I don't think this can be the solution. This line is there for a reason I assume. Anybody with a deep understanding of NuGet who might know how to properly resolve this problem?
Update 2
I found out that as soon as you reload your solution/project, the line gets added once again. Also, if you have certain dependencies nuget should download for you - it won't, because the line which makes that call and handles this got removed.
I'm now at a point where I know where the problem is but not why it is caused.
Does ReSharper change anything in the way NuGet behaves? As far as I can tell, nothing gets added or removed to or from the NuGet.targets file due to ReSharper.
There were one more report on this topic, at https://youtrack.jetbrains.com/issue/RSRP-462271 .
The best guess so far is that this is caused by two things happening at once: (a) using MSBuild tasks in C# source code form inside MSBuild XML files rather than DLLs and (b) having some of the MSBuild opensource DLLs shipped with the latest version of ReSharper for its own project file handling needs.
The source code gets compiled into a task DLL during an MSBuild run (not a much common thing to have; Roslyn would do this rather than ship a DLL? seriously?). When building from within Visual Studio (rather than with msbuild.exe), the in-process MSBuild instance is used, and it would run in the same appdomain as ReSharper, so it uses the common assembly reference resoluiton. If it's not too accurate, then it might accidentally pick the wrong DLL version by the short name, which would break the task compilation (that's a separate error, maybe cached away) and then result in the task-not-found error later at runtime (SetEnvironmentVariable task not found in here case).
I've tested on sample solutions with source code based tasks and could not get it broken. So trivial cases are OK. Never heard back from the original issue reporter, so there was no further progress.
Now I've got a hint that this is Visual Studio 10 (any other VS versions installed on that machine?) and maaaaybe it's Roslyn tasks. We might know for sure if you run MSBuild with more detailed logs (by setting the logging options at Tools | Options | Projects and Solutions | Build and Run | MSBuild project build output verbosity to at least Detailed) and building just the faulty project.
I'll also try this out with VS10 and update this reply with new data.
We are currently evaluating the new Visual Studio 2015 and encountered a strange problem with IntelliSense. When I compiled our main solution with the new studio the build succeeds, but nevertheless 6 errors are shown.
I discovered that it's not a real error, but only an intellisense error. The code is definitely correct and everything compiled successfully. The code however is marked red and errors show up in the error list.
All 6 errors have the same origin. It's a simple constructor call. Strange enough, but there are also some occurrences of the exact same constructor without any errors.
The error message:
Code: CS1729
Message: '<the class>' does not contain a constructor that takes that many arguments.
Project: <the project name>
File: <the path to the file>
The new studio was installed on a freshly installed Windows 7 without any legacy software (no VS13).
I've already tried to clear the caches, deleted the suo file, deleted bin and obj directories, cleaned and rebuilt the solution etc. But nothing worked.
Can anyone explain that behavior to me?
I had thousands of intellisense errors and 0 build errors. After deleting .suo file and restarting VS intellisense errors are gone.
Suo file is located relatively to source in:
.vs\SolutionName\v14\.suo
According to comment: Beware that *.suo is a hidden file.
Edit: According to comments, VS2017 has the same issue, so you can use similar solution: Delete .vs\SolutionName\v15\.suo
VS2019 still has this issue. Delete .vs\SolutionName\v17\.suo
If deleting .suo still does solve your problem, then delete also all bin and obj directories in every project in the solution.
Also had this problem with a migrated project, so I referenced the Microsoft.CSharp dll. In some projects I needed to remove and add again the Reference in the project.
Ran into similar issue in Visual Studio 2017 ASP.Net Core Project. Following steps did the trick for me
Perform Clean Solution
Close VS
Delete .suo file & Delete bin/obj directories
Reopen VS
Similar problem as others, but different resolution. Posting in case I can help someone else.
Running Visual Studio 2017 15.5.2. I use Git and frequently switch branches. Several weeks ago, I started having editors show me errors (all related to types it could not find even though references were valid). Compile worked great. I confirmed the same issue in VS 2017 15.6 Preview (Jan 6, 2018). I would try to delete cache, SUO files, or bin/obj folders and no impact. At first it would appear to work. Reopen Visual Studio and everything would look good. Use "Rebuild Solution" and the IntelliSense errors would returns. I even tried uninstall/reinstall of Visual Studio.
I had the same issue on two machines, both with same version of Visual Studio.
By looking at the errors about missing types, they all appeared to come from two referenced projects. One of those references was a shared project used by just about every other project in the solution, but one of them was a small project without many references. It just so happens that the small project was also referenced by my larger shared project. In Visual Studio, I unloaded the small project and reloaded it. The errors went away! They errors did not come back on Rebuild Solution.
I then switched Git branches and the errors all came back. Fortunately I repeated the above steps of unloading/reloading the small project and the errors went away.
Every time I switch Git branches, the errors come back until I repeat that process. There are zero changes between the Git branches for the smaller project that I unload/reload. Unclear why that sequence is fixing my issue.
Also had this problem (the title, not the specific error message), as well as squiggly lines in the editor. The first squiggly line is under the first #include statement, which names a precompiled header. Intellisense fails to include the precompiled header, but doesn't list that as an error; instead it lists errors further down the file, on code that (very rightfully) relies on declarations in the precompiled header.
The reason Intellisense doesn't find the precompiled header in my environment is that the header named is not an actual file. It doesn't have to be in any other VC or gcc version I used, nor in the 2015 compiler, as long as the precompiled header settings are correctly configured. Apparently not any more for Intellisense. I'm not entirely sure it was different in 2013, maybe I just never noticed.
In the unlikely case that this would be the problem reported here, the solution is simple: create a small file with the pretend-name of the precompiled header, as specified in #include directives, and let that file include the actual name of the precompiled header.
If you wonder... why this distinction between the precompiled header name in the '#include' statement and the actual filename of the precompiled header? Precisely because it guarantees that precompiled header settings are correctly configured. Wherever a precompiled header is "#included", there is no file around that could be included. Either an actually precompiled (binary) version of the actual header is read, or the compilation fails. Obviously, a disadvantage is that it confuses people reading the code, not just Intellisense.
Visual Studio 2017
I have deleted ".suo" file from location .vs\SolutionName\v15.suo
And then restarted Visual studio. This worked for me.
Today I've had similar problem with MSVC++ 2015. I almost gave up and decided to go on without IDE hints, but suddenly I've noticed that stdafx.h of the project i had problems with doesn't contain any standard library headers. I've speculated that inclusion of all standard headers used in the project in stdafx.h might boost up compilation speed, however doing so fixed Intellisense errors as well.
In Visual Studio 2019 the problem is with changing branches with Git when there are NuGet packages installed in the project. What I did to solve this:
Clean Solution
Close Visual Studio
Delete the packages folder
Open Visual Studio
Go to Package Manager
Restore all packages
Recompile
If roslyn is missing, close and open Visual Studio, then recompile.
I had multiple stdfax.h in Additional Include Directories. Make sure the stdafx.h you intended is first in your path.
I had a similar issue with different Visual Studio versions.
Deleting the .suo or .vs folder did not help for me.
The Solution for me was, that I had the Extension StopOnFirstBuildError active. After turning off "Stop build on first error" in the build menu, and after the solution was fully built, the errors shown by Intellisense went away.
I was seeing the intellisearch errors only when publishing a website. (ASP/C# site, VS 2017). They broke the publish. Site ran fine locally.
Cleared the errors by unchecking the setting to pre-compile, and it published fine.
Publish -> Setting -> File Publish Options -> Precompile during publishing
I had this issue with a reference to another project. Removing and re-adding the project reference worked for me.
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.
We have a WinForms application, targeting .NET 3.5.
Loading it up into VS2010 works fine, editing form layouts using the forms designer is fine initially, then we compile and run.
However, after that, pretty much any change to the layout of a form (sometimes just a solution rebuild) will break the designer.
The error we get is:
Could not load file or assembly 'OurControls, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
Restarting VS2010 and reloading the solution will cure it, but only for a couple of edits before it recurs.
The project referred to in the message contains a bunch of home-grown controls that we use in the application. It's as if a Rebuild Solution causes VS lose its ability to reference it - but as I say, it has no problem on initial load.
We never had this with VS2008, and the solution is a straight upgrade from then.
Any suggestions would be greatly appreciated.. it's not yet practical to migrate to .NET 4, unfortunately, or to WPF!
Edit:
The folder structure is as follows:
Solution Folder
. Projects folder
.. Project A
.. Project B etc
The startup project, containing the forms, is in one of the folders A, B etc. The OurControls that it can't find, is one of the others at that level.
On initially opening the solution, all projects load correctly, and there are no errors or reference warnings.
On initial rebuild after opening the solution, all the project folders get their respective DLLs correctly.
A 'Clean Solution' does not solve the problem.
It's a VS2010 bug, see
https://connect.microsoft.com/VisualStudio/feedback/details/709080/after-working-for-a-while-vs-designer-stops-to-regnize-types-and-does-not-allow-designing-winforms#.
You could sending them a dump file when it happens , since it's easy for me to reproduce/send dump files to MS.
Not a fix, but in Visual Studio 2010 I've found out that the quickest way to get the form designer back on track is unload/reload the project where the form is in. Don't know if it always helps, but it is quicker than restarting visual studio.
Let's see if VS 2012 is better.
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.