I've run into an issue with an SSIS package in Visual Studio 2010 and 2012. When I try to open the package I get the following error:
"Microsoft Visual Studio is unable to load this document
Exception from HRESULT: 0xC0010009"
No other information is provided. I have multiple SSIS packages in the solution and the others open. This package opened until I checked it into TFS and then it broke. Any ideas where I could get more information on the error? Or how to solve it?
Don't know if this is related, but thought I'd throw it out there.
Using SSIS Version 12.0.21005.1 REL, I received the same error and was able to solve it by editing the .dtsx with a good xml editor (hat tip to notepad++).
Basically, ensure it is well formed and all references agree. For example, in a simple ETL package with OLE DB Source, Transformation, and Output steps in a DataFlow, I found 24 references to each column involved. For one column, one reference somehow disagreed with the other 23 (it ended up being misspelled; not sure how that happened). Fixing that solved the error.
Hope that helps.
Related
Just installed ODAC for Visual Studio 2017 version 19.3 from here: https://www.oracle.com/database/technologies/dotnet-odacmsi-vs2017-downloads.html to replace ODT for Visual Studio 2017 NuGet Package. Then I noticed my Oracle NuGet packages were gone in my VS solution, and I had to re-add them. But this time I used Oracle.ManagedDataAccess 19.3 (previously had used 12.2.1100), and Oracle.ManagedDataAccess.EntityFramework 19.3 (previously used 12.2.1100).
Now my EDMX gets an error when I try to open it: "Error 168: The provider did not return a ProviderManifest instance. The type initializer for 'OracleInternal.Common.ProviderConfig' threw an exception."
I found an interesting answer by Mitaka here: Entity Framework: The provider did not return a providermanifest instance, so I opened my EDMX with XML Text Editor and found my ProviderManifestToken="12.1". So just for grins, I tried "19.3" and "19.1" but neither worked.
Anybody know the magic value? I'm just hoping that is how to solve the error. Thanks.
Got it. "18.0"
It actually updated itself after I got a bunch of other kinks worked out including "There is a duplicate 'oracle.manageddataaccess.client' section defined." Turns out the definition for Oracle.ManagedDataAccess was in my WebAPI web.config and also the machine config. Had to update THIS specific machine.config:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config - do a search on "managed" and comment out in 3 places.
Then it let me create a connection in Visual Studio 2017 Server Explorer and open the EDMX. Finally the EDMX update wizard is no longer aborting on the Data Connection screen. Back in business.
I am using VS 2013 and SQL SERVER 2014 and I am trying to use entity framework to connect to the DB from VS 2013. I am getting test connection succeeded when adding the Entity data model but getting the above error.
Error :Could not load file or assembly 'Microsoft.SqlServer.Management.Sdk.Sfc, Version=11.0.0.0'
System cannot find the file specified
I tried so many solution, I re-installed SQLSysClrTypes.msi,
SharedManagementObjects.msi, DB2OLEDBV5_x64.msi and vcredist_x64.exe to resolve this ; but it did n't works.
Could any one please suggest me solution?
Thanks,
Saloni
Just to stamp as the answer, let me rewrite in the answer block from my comments.
Install the right Microsoft.SqlServer.Management.Sdk.Sfc version 11's SharedManagementObjects.msi from http://www.microsoft.com/en-us/download/details.aspx?id=35580, because it seems like the entity is using the previous SQL Server (2012).
Problem: (Sql server 2012) This issue happens when assembly Microsoft.SqlServer.management.sdk.sfc version 11.0.0.0 not found by visual studio.
Solution: just go to http://www.microsoft.com/en-us/download/details.aspx?id=35580 and download:
ENU\x64\SharedManagementObjects.msi for X64 OS or
ENU\x86\SharedManagementObjects.msi for X86 OS,
then install it, and restart visual studio.
Recently upgraded to VS 2010 from 2008, the previously built solutions are throwing the following error.
Error 14 Encountered multiple versions of the assembly with GUID 'a5851ea0-2f9a-40b2-a73a-cd7db32f09c5'. Try pre-importing one of these assemblies
I tried re-installing VS 2010 and it didnot help. Any ideas?
Is it the VS 2010 application itself crashing, or does it not like your solution? Can you open VS 2010 by itself? If so, it sounds like it doesn't like some of your references in one or more of your projects. Check the project references. If that doesn't work, start removing projects until you find the offending one.
This may happen, if you copy-paste-renamed a project file to re-use its settings but didn't changed the project GUID of it. Also could be a project migration error, anyway you will have to manually edit the project file and remove the duplicate references if the project fails to load because of the error.
I had the same issue when migrating 2008 -> 2013.
It was caused that we use same linked AssemblyInfo.cs for all projects in solution.
And only for the assembly that used some COM objects (MSMQ) it seems that it starts looking on referenced assemblies GUID and two of them from our solution...
So when I provide individual AssemblyInfo.cs for projects with unique GUIDs it start working.
Hope this info will helpful.
Try to remove the references to the debug folder.
In Visual Studio right click on Project
Select Properties
Select the references tab.
Check to see if any of the references are from the obj\Debug folder and remove them.
See similar question here.
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.
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.