1

I need to build a vdproj on a jenkins machine (Windows Server 2012 R2)- which requires devenv.exe and not msbuild. I cannot install Visual Studio. Devenv.exe is required for a MSI package.

I've used process monitor and determined I require one more file for devenv.exe to work : api-ms-win-core-heap-l2-1-0.dll

This file does not exist on any developer machine that we have, and devenv.exe/devenv.com works on the dev machines.

Where can I find this file? Are there other ways to build a vdproj without Visual Studio?

enter image description here

Peter PitLock
  • 1,823
  • 7
  • 34
  • 71

1 Answers1

1

Virtual Machine: This sounds a little hairy I am afraid. Could you use a virtual machine - with Visual Studio on it - to build the Visual Studio Installer project in question?

WiX et al: Converting to WiX or another deployment tool besides Visual Studio Installer Projects would solve the problem? Is this a very complicated installer? Using the WiX decompiler dark.exe to decompile an MSI to WiX markup can help you convert the installer to WiX format. Quite a bit of WiX knowledge will be required to do this successfully. Maybe something a consultant could do quickly? Depends on the complexity.

Windows API-set: As far as I know api-ms-win-core-heap-l2-1-0.dll is a Windows API-set, and not a real file or real dependency as such. These are new constructs in Windows. Try opening such an API-set file with Dependency Walker to see what they redirect to. Pretty mysterious these API-sets:

An API Set is a strong name for a list of Win32 APIs. The convention for assigning a strong name to an API Set is to use what appears to be a dll name. But the purpose of an API Set is to provide architectural separation between the API Set's name and its associated host DLL implementation for improved portability of your app, so you should think of an API Set's name as just a unique character string, and not as a dll name. For delay load, you use the name of the API Set.

API Sets rely on operating system support in the library loader to effectively introduce a namespace redirection component into the library binding process. Subject to various inputs, including the API Set name and the binding (import) context, the library loader performs a runtime redirection of the reference to a target host binary that houses the appropriate implementation of the API Set.

The decoupling between implementation and interface contracts provided by API Sets offers many engineering advantages, but can also potentially reduce the number of DLLs loaded in a process.

On disk I find most of these API-Sets in %SystemRoot%\WinSxS and %SystemRoot%\System32\downlevel.

Nice article on the technical aspects of this new API-Set feature.

Complex Executable: Though devenv.exe is just an EXE file like any other, I do think there will be dependencies for Visual Studio Installer Projects beyond just dll import tables that will be very hard to set up properly, and what about future releases when all can fail without warning? (if something changes - Visual Studio has been a pretty moving target of late).

WiX Quick Start: Here are some of the best links that I have found over time for WiX:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thank your for a fantastic answer Stein - we are moving to Wix. – Peter PitLock Nov 28 '18 at 11:09
  • That sounds like the best long term, yes. I should have added a couple of direct links for WiX quick start. Let me do that to the answer above. – Stein Åsmul Nov 28 '18 at 12:00
  • I have now updated the answer with links to help you with your WiX quick-start process. Always remember that you can pillage [github.com](https://github.com/search?l=XML&q=wix+sample&type=Code) for WiX XML constructs - be sure to run them by a good consultant if you do not understand it all. **Please remember that in deployment problems are better removed than solved**. To quote Obama: don't do stupid s.... (I have indeed done so many times - no cure for that but to get rid of such constructs). If it looks too complex and vulnerable, it is. And `dark.exe` to decompile existing setups and tune. – Stein Åsmul Nov 28 '18 at 12:07
  • Why should you remove rather than solve deployment problems if you can? Because you are dealing with largely unmanageable complexity. Complexity that can't always be handled well. Some details on this complexity mid-answer here: [Windows Installer and the creation of WiX and the complexity of deployment](https://stackoverflow.com/a/12101548/129130). The solution: minimize risk everywhere. Stay simple. As simple as possible. And stay standard! Don't fight MSI, it fights back. – Stein Åsmul Nov 28 '18 at 12:33
  • And a chaotic summary from the real world that I wrote. Not great. Not even close, but it tries to be helpful by writing what isn't written in books (for good reason - too messy): [How do I avoid common design flaws in my WiX / MSI deployment solution?](https://stackoverflow.com/questions/45840086/how-do-i-avoid-common-design-flaws-in-my-wix-msi-deployment-solution/45840087#45840087). – Stein Åsmul Nov 28 '18 at 12:36