I have downloaded and installed the free Community Edition of VS 2015 from Microsoft. After the install, I am unable to use VS 2013 Professional, which was working fine before the install. The start page shows, "Content Load Error". The solution explorer shows the following errors:
An exception was encountered while constructing the content of this frame. This information is also logged in "C:\Users\VeluMain\AppData\Roaming\Microsoft\VisualStudio\12.0\ActivityLog.xml".
Exception details:
System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Microsoft.VisualStudio.Shell.Interop.IVsShell5.LoadPackageWithContext(Guid& packageGuid, Int32 reason, Guid& context)
at Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.GetPackage()
at Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.ConstructContent()
I searched in Google, but couldn't find any solution.
Thanks
It's possible that one of your plugins for VS2013 has been broken by the VS2015 installer. For example I had an issue where VS2015 installer also installed .NET Framework 4.6 which alters the .NET Framework 4.5.1 DLLs, I guess there's a chance it could be the same kind of thing...
Try running VS2013 in Safe Mode (i.e. without plugins). If this works fine then you know it's one of your plugins that is causing the issue, you should then use a process of elimination to determine which one is the culprit. If it doesn't work then you might want to reinstall VS2013.
Related
I am loading my project into Visual Studio 2019 IDE. When I go into the forms designer within the IDE
Visual Studio Forms Designer has been gives me the following error:
An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.
There is no code associated with it. All referenced DLLs haven't changed.
Has anyone else experienced this or have a work around as the Google searches I have done have given me to help. Is there a way to narrow down the error? I have also checked all the security dlls to make sure they are correct and are referenced locally to help. Maybe something to do with the CAS policy?
I have also tried on my installed versions of 2012, 2015, & 2017.
UPDATE: Updated the error above as I had the wrong error added.
Good morning.
I've searched over the web and Microsoft's documentantion and didn't see any matches for the same error. When I click New Project, on Visual Studio 2015, I receive the following error:
Library is not registered. (Exception from HTRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
There are evidences that the error may be on .NET 4.6, which VS 2015 requires, but reinstalling it didn't solve the problem.
I've found no matches and no way to solve it. Did anybody here deal with the same problem?
Footnote: It's not about removing libraries. The error happens by a simple click on New Project.
When I try to register a visual studio package using regpkg in Visual Studio 11 RC, I get the following error:
regpkg.exe /root:Software\Microsoft\VisualStudio\11.0 /codebase myvspackage.dll
Could not load file or assembly 'Microsoft.VisualStudio.Shell, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.
This worked fine with previous versions of Visual Studio. I'm working in a clean virtual machine that only has Visual Studio 2012 RC.
I've been surfing the web looking for a solution with no success.
If I just copy the Microsoft.VisualStudio.Shell.dll in my app location it works fine, but this dll is not redistributable, so... what's the right way of registering a package in Visual Studio 11?
Thanks in advance for your help,
Luis
I'll assume you also posted this to the MSDN forums since a question with identical text was posted there which I answered yesterday.
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/96556cd4-44dd-4e01-8198-b83a66c6df26
In short it sounds like you have an explicit reference to v2 of Microsoft.VisualStudio.Shell.dll, James is incorrect in saying you aren't supposed to use this, this is simply MPF from 2005. Referencing it is perfectly fine. If you have an explicit version in the reference in the project file try dropping it, if not try adding the binding redirect mentioned in my MSDN forum post.
I have started a mail with the SDK team about this issue though I don't know if they will be taking any changes this close to release. Also, as an FYI, since Shell.dll is from 2005, it is nearing the end of its supported life, we generally support three versions of previous VS releases.
On release of 2012 the support will be 2008,2010, 2012. I suspect in the next release (after 2012) we may stop including Shell.dll (the 2005 version) entirely in the shipped product. Unless you need to run downlevel on say 2005 I would update the reference to one of the newer shell assemblies (like 9.0, 10.0 or 11.0)
I tried to start Visual Studio and it said: "This application has failed to start because ATL100.DLL was not found. Re-installing the application may fix this problem".
I don't want to reinstall it (time consuming).
I also just uninstalled all the C++ stuff (I don't do any C++ work, so I got rid of it).
So does anyone know?
If the ATL100.DLL is missing you're likely just seeing the first missing file of a now corrupted installation. If you don't want to do a full reinstall you can attempt to repair the installation from your install source but there's no easy fix for this.
http://msdn.microsoft.com/en-us/library/e2h7fzkw.aspx#repair
You need to have the MS VC++ 2010 redistributable pack installed on the client machine.
You should also link your program against the release version of the redist pack and not distribute a debug version of the VC++ runtime (msvcr100d.dll) as its release counterpart is part of the VS2010 redistributable pack, as described here. The ATL100.dll is also part of that pack. MS has strict policies about which dll can be distributed with the application. A previous post about DWMAPI.DLL will help to sort out that problem.
source:iodocs.com
(I'm running Windows7 and using Visual Studio 2010.)
I'm using ClamAV in a .NET Azure project, and I'm running into side-by-side errors whenever I run clamd.exe, either through my code or by running clamd.exe on it's own.
In Visual Studio 2010 I am getting the error:
Win32Exception was unhandled The application has failed to start
because its side-by-side configuration is incorrect. Please see the
application event log or use the command-line sxstrace.exe tool for
more detail
And in Event Viewer I get:
Activation context generation failed for
"C:\Users\pconerly\code\AntiVirus_source\WorkerRole\clamav\clamd.exe".
Dependent Assembly
Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
could not be found. Please use sxstrace.exe for detailed diagnosis.
When I searched for "8.0.50727.6195" it led me to the 2005 redist, so I downloaded it
http://www.microsoft.com/download/en/details.aspx?id=3387
After a restart I am still getting the side-by-side error. Additionally, I think that the redist installer is not completing it's install-- like it's seeing visual studio 2010 and saying "oh, that's good enough, no need for me to install". I haven't tried uninstalling 2010 and using 2005, because the rest of my Dev team is using VS 2010.
What's the deal? How can this be fixed? I'm ready to pull out my hair.
The link Timores posted is the update for Visual Studio. The actual redistributable package is this:
http://www.microsoft.com/en-us/download/details.aspx?id=26347
The version you mention is actually at found here
Microsoft Visual Studio 2005 Service Pack 1 MFC Security Update
Timores is right: the redist should be this one, which is related to this KB entry
As you can see there, msvcr80.dll has been updated to version 8.0.50727.6195.
It is the "security update" of the "SP1" of the 2005 C++ runtime..
Your exe probably requires (through an internal manifest) that specific version.
If it is not found on the system (there's a lot of places searched for) nor in the current folder (with a suitable manifest aside) it won't load the exe since it is not able to "activate the context", that is load the specific DLL required in the manifest.
I had similar issues when my system got updated (windows updates) and the newly compiled EXEs were not working with an old-versioned runtime placed on the same folder.
I had to update msvcr80.dll and its manifest (which I found deep in \windows\winsxs) to make everything work.
Context activation is a tricky matter, anyway :)
HTH