Related
I am getting this message while using integration studio on windows:
Save could not be completed.
Reason: resources\GreetingsAPI.esb_diagram(The system cannot find the path specified)
enter image description here
I am trying to run a certain application but when i get the following error whilel loading a dll:
"Windows API LoadLibraryEx returened error # 14001 ( 0x36B1)..."
I opened windows event viewer and got this error:
Dependent Assembly Microsoft.VC90.DebugMFC could not be found and Last Error was The referenced assembly is not installed on your system.
My question is, what is Microsoft.VC90.DebugMFC ?
Installing Visual studio professional 2008 SP1 solved the problem
I'm building a new TFS build server and decided to use the VS 2017 Build Tools instead of installing the full versions of VS. When I attempt to build our C++ projects, it throws the following error:
Error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found.
After many hours of research I'm no closer to resolving this issue. I tried adding the following registry settings but it did not help.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
I'm guessing Microsoft's installer is broken for this product. Is there a standard fix for this error or should I scrap my efforts and simply install the full versions?
In the project file, I found this entry:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
So, I guess this means that the variable VSTargetsPath is somehow pointing to the root of the D: drive but I haven't got a clue where that value is being set. Our current build server does not have an environment variable set named VSTargetsPath, but it does have the missing registry entries. It also has full versions of VS installed.
VS 2017 Build Tools failing with Error MSB4019: The imported project “D:\Microsoft.Cpp.Default.props” was not found
Try to pass VCTargetsPath explicitly as property to msbuild from your build configuration:
Edit the build definition for the build.
Click the process tab.
In the Advanced section, set the MSBuild Arguments to include the following property:
/p:VCTargetsPath="C:\Program Files (x86)\Microsoft Visual Studio\2017\xxx\Common7\IDE\VC\VCTargets\"
Save the build definition.
Note: You should change the value of VCTargetsPath to the location of the VCTargets folder.
Or pass VisualStudioVersion as property to msbuild:/p:VisualStudioVersion=15.0
If you are interesting in the value of $(VCTargetsPath), you can check following threads for some more details:
Can't find registry entries for Visual Studio 2017
Visual Studio Locator
Over the years Visual Studio could be discovered using registry keys,
but with recent changes to the deployment and extensibility models a
new method is needed to discover possibly more than once installed
instance. These changes facilitate a smaller, faster default install
complimented by on-demand install of other workloads and components.
vswhere is designed to be a redistributable, single-file executable
that can be used in build or deployment scripts to find where Visual
Studio - or other products in the Visual Studio family - is located.
For example, if you know the relative path to MSBuild, you can find
the root of the Visual Studio install and combine the paths to find
what you need.
You can emit different formats for information based on what your
scripts can consume, including plain text, JSON, and XML. Pull
requests may be accepted for other common formats as well.
vswhere is included with the installer as of Visual Studio 2017
version 15.2 and later, and can be found at the following location:
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe.
I have the problem described here.
Any attempt to install AspNetDiagnosticPack.msi
C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.VisualStudio.AspNetDiagnosticPack.Msi,version=15.0.40314.0\AspNetDiagnosticPack.msi fails with error status: 1603.
I cannot add or remove any component using VS installer now.
I have installed VS 2017 Professional as follows:
Microsoft Visual Studio Professional 2017
Version 15.6.6
VisualStudio.15.Release/15.6.6+27428.2037
Microsoft .NET Framework
Version 4.7.02558
Installed Version: Professional
Visual C++ 2017 00370-20001-54960-AA753
Microsoft Visual C++ 2017
Visual F# Tools 10.1 for F# 4.1 00370-20001-54960-AA753
Microsoft Visual F# Tools 10.1 for F# 4.1
Application Insights Tools for Visual Studio Package 8.11.10402.2
Application Insights Tools for Visual Studio
ASP.NET and Web Tools 2017 15.0.40314.0
ASP.NET and Web Tools 2017
Azure App Service Tools v3.0.0 15.0.40215.0
Azure App Service Tools v3.0.0
C# Tools 2.7.0-beta3-62715-05. Commit Hash: db02128e6e3c4bdfc93e6ec425ac9162b4d4fe80
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
Cookiecutter 15.6.18072.2
Provides tools for finding, instantiating and customizing templates in cookiecutter format.
Dotfuscator Community Edition 5.32.1.6167-6ce295ebd
PreEmptive Protection - Dotfuscator CE
JavaScript Language Service 2.0
JavaScript Language Service
JavaScript Project System 2.0
JavaScript Project System
Microsoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 2017 - v2.9.51212.2
Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines
Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers
Microsoft Visual C++ Wizards 1.0
Microsoft Visual C++ Wizards
Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package
Node.js Tools 1.4.11027.3
Adds support for developing and debugging Node.js apps in Visual Studio
NuGet Package Manager 4.6.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.
ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info
Python 15.6.18072.2
Provides IntelliSense, projects, templates, debugging, interactive windows, and other support for Python developers.
Python - Django support 15.6.18072.2
Provides templates and integration for the Django web framework.
Python - IronPython support 15.6.18072.2
Provides templates and integration for IronPython-based projects.
Python - Profiling support 15.6.18072.2
Profiling support for Python projects.
SQL Server Data Tools 15.1.61801.210
Microsoft SQL Server Data Tools
TypeScript Tools 15.6.20202.3
TypeScript Tools for Microsoft Visual Studio
Visual Basic Tools 2.7.0-beta3-62715-05. Commit Hash: db02128e6e3c4bdfc93e6ec425ac9162b4d4fe80
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio
I thought that the problem originated in having some remains from previous VS editions. I could not uninstall namely ASP.NET and Web Tools 2013.1. I have finally removed it after all by reinstalling VS 2015 and using the FixIt tool from this answer.. But still AspNetDiagnosticPack.msi fails the same way.
I also tried to uninstall the web development role completely, since I will probably not use it soon, but installation allways fails. Is there any workaround to make the VS installer work again?
The msi log is here.
Action 15:50:02: WebConfigInitialize.
Action start 15:50:02: WebConfigInitialize.
MSI (s) (B8:F4) [15:50:02:244]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIFF27.tmp, Entrypoint: Initialize
MSI (s) (B8:40) [15:50:02:244]: Generating random cookie.
MSI (s) (B8:40) [15:50:02:244]: Created Custom Action Server with PID 10588 (0x295C).
MSI (s) (B8:14) [15:50:02:306]: Running as a service.
MSI (s) (B8:14) [15:50:02:306]: Hello, I'm your 32bit Impersonated custom action server.
SFXCA: Failed to create new CA process via RUNDLL32. Error code: 2
CustomAction WebConfigInitialize returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 15:50:02: WebConfigInitialize. Return value 3.
But the problem is within custom action WebConfigInitialize and the log is no big help. I have observed that there was an entry Microsoft ASP.NET and Web Tools 2015.1 - Visual Studio 2015 when I ran the uninstaller tool - and this entry failed uninstalling. Perhaps the origin of my problems is that I once installed some beta verison of ASP.NET with Visual Studio 2015. I do not need ASP.NET for now, but I the VS 2017 installer is stuck on the error.
I have found WebToolsExtensionsVS14_rc2_48.msi in cached packages on my computer and uninstalling this package fails the same way with 1603 as the 2017 current package.
Action 8:30:41: WebConfigInitialize.
Action start 8:30:42: WebConfigInitialize.
MSI (s) (48:BC) [08:30:42:012]: Creating MSIHANDLE (550) of type 790542 for thread 1980
MSI (s) (48:F0) [08:30:42:012]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA2E1.tmp, Entrypoint: Initialize
MSI (s) (48!A0) [08:30:42:028]: Creating MSIHANDLE (551) of type 790531 for thread 928
SFXCA: Failed to create new CA process via RUNDLL32. Error code: 2
MSI (s) (48!A0) [08:30:42:028]: Closing MSIHANDLE (551) of type 790531 for thread 928
CustomAction WebConfigInitialize returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (48:F0) [08:30:42:028]: Closing MSIHANDLE (550) of type 790542 for thread 1980
Action ended 8:30:42: WebConfigInitialize. Return value 3.
Similar problem here, that one ended with reninstalling his machine.
Or is there some tool that would show the dependencies of a particular MSI package?
The Developer's community link that is current and relevant to the problem is here.
It says:
We have fixed the problem in an upcoming release. We've addressed the
managed custom action in the ASP.NET Diagnostic Pack that modifies the
root web.config file to use a native code action. This should avoid
the CLR errors previously reported when it tried to launch the managed
code DLL during the install.
The fix for this is now in our latest Visual Studio Preview release.
If you'd like to try out the fix, you can access the preview build
here: https://www.visualstudio.com/vs/preview
Looks like there is no workaround except waiting for Microsoft's fix to that faliling custom action. I have ignored this recommendation at first because I did not check the date of comments properly but they are only one month old.
But when I have tried to install the preview it ended with exactly the same error.
In 15.7.1 version the same error again.
UPDATE: It looks like the issue might be a managed code custom action failing in the MSI in question (.NET code that can't run - for whatever reason 1, 2, 3).
Suggestion
I would first try to 1) do the reboot I recommend below - to clear the air and release any locks - then 2) disable security software / anti-virus and 3) try the install and enable logging as described below.
Core Deployment Problems
As deployment goes, problems tend to center around: 1) something is locked (in use - by other processes or other users logged on), 2) something is blocked (access / permissions denied), 3) dependencies are missing for your custom actions or the whole installer (runtime requirements not satisfied - for example missing .NET runtime version), 4) something is corrupted (data file, OS settings, malware is often the culprit here - or unwise tinkering), 5) there is an unexpected system state such as the disk being full, or more exotic the date and time is wrong, or there is a licensing issue or some other oddity, etc...
That is a very simplified list of causes - there are obviously many further issues, for example 6) localization errors: hard coded paths, erroneous parsing of dates and time, invalid characters in path names, etc... 7) file and path names are too long, 8) and the Microsoft specialty: weird and unexpected incompatibilities between products not thought to have a valid reason to conflict with each other (different versions of Visual Studio, etc...), etc..., but that is going way too far for your problem. Still, here is a generic "deployment problems" summary from some time back - just for reference.
Procedure
Reboot: The first thing I would do is to reboot and then try to invoke the install the regular way. This is just to rule out this "simple solution" (which sometimes works). There could be files in use that the installer must replace in order to complete.
Logging: In order to maximize the available debugging information you could log the install with verbose logging and debugging information (if you have access to the MSI itself).
Open an elevated command prompt (right click and run as administrator)
Change current directory (cd) until you get to: C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.VisualStudio.AspNetDiagnosticPack.Msi,version=15.0.40314.0\
MSI Log: Run this command (adjusting paths as appropriate - especially for the log file): msiexec.exe /i AspNetDiagnosticPack.msi /L*vx C:\Test.log
Enable All: You can enable logging for all MSI files (slows installs, but great for advanced users): http://www.installsite.org/pages/en/msifaq/a/1022.htm (section: "Globally for all setups on a machine")
Interpret: How to interpret an MSI log file: http://www.installsite.org/pages/en/msifaq/a/1045.htm
Event Log: You can also have a look in the event log. Rather than repeating the procedure here, I will link to a similar, recent answer.
Different User: This is unusual advice (and I haven't tried it), but sometimes you can succeed with difficult installs by creating a new local admin user on the machine, and then running the installer from there. It has to do with errors in the user profile. Not the first thing to try, but adding it as an option.
I tried to uninstall VS 2019(!) and I faced the same problem (I cannot add or remove any component using VS installer).
It hang for a long time and finally throwed an error at "AspNetDiagnosticPack.msi".
I found a solution that led me also to
%programdata%Microsoft\VisualStudio\Packages\Microsoft.VisualStudio.AspNetDiagnosticPack.Msi,version=16.3.283.64955
I simply ran the msi stand alone. During the process I was asked to do kind of clean up for an outstanding installation issue.
After that I ran the uninstall ( And later the reinstallation ) of VS 2019 again and it worked.
Maybe this solution helps you along with VS 2017
I have a COM+ application which builds and run under Microsoft Visual Studio Professional 2005 libraries, which I am trying to port to a newer VS version. So I first tried with a new SDK for Windows, which failed in the registration phase. After, I tried with VS 2010 Express SP1, which also failed in the app registration phase.
While investigating why the app works with VS2005 and not works with VS2010, I discovered that the VS2005 installation has the following libraries (actually if I install only this, the app COM registration works clean), which I did not find as the other one, in the VS2010:
+- Microsoft Visual Studio 2005 Professional Edition
+- Visual C++
+- Visual C++ Run-Time Libraries
+- Visual C++ Static Multi-Threaded CF
So I tried also to get the Visual C++ Static Multi-Threaded CF for VS2010, but no success. I only found several versions of redistributable libraries which did not work.
The error when I try to register the application is the 0xc0150002 ("The application was unable to start correctly (0xc0150002). Clock OK to close the application"). I also looked for this error, but it seemed to be very generic, and no other clues were found.
Does someone know how to solve this? Please!
Update 1
Looking in the Windows Event Viewer / Customs Views / Administrative Events, I found the following error:
Activation context generation failed for
"C:\Users\root\Desktop\OMNI\bin\BLK_ENTRY.dll".Error in manifest or
policy file
"C:\Users\root\Desktop\OMNI\bin\Microsoft.VC80.OpenMP.MANIFEST" on
line 5. Component identity found in manifest does not match the
identity of the component requested. Reference is
Microsoft.VC80.OpenMP,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
Definition is
Microsoft.VC80.OpenMP,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.42".
Please use sxstrace.exe for detailed diagnosis.
Update 2
Looking at the same event log, I found the following error (before trying to install reinstall the libraries)
Activation context generation failed for
"C:\Users\root\Desktop\OMNI\bin\BLK_ENTRY.dll". Dependent Assembly
Microsoft.VC80.OpenMP,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
could not be found. Please use sxstrace.exe for detailed diagnosis.