Where can I find a good reference that explains how to write and install a SxS policy redirecting from one native assembly version to another?
I've already succeeded in building and installing two versions of my native assembly using a wix installer. But I'm not sure how to proceed from here. Most of the information I've found is about managed assemblies and the GAC. Is the procedure I'm looking for identical to that of managed dlls?
Thanks for the help,
Dan
[I'm the current maintainer for Native SxS at Microsoft]
Hi Dan,
A Publisher Policy is a special type of assembly. It's installed in the same way as any other assembly, but with type="win32-policy" and name="policy.MAJMINVERSION.name"
You can read more about it here
or you could look at how the CRT's policy is authored. On my Vista machine, it's located under
%windir%\winsxs\manifests\x86_policy.8.0.microsoft.vc80.crt_....manifest
Since it seems you are authoring a new assembly, providing a publisher policy just yet may not be necessary, as it only comes into play when it comes time to service your assembly (by redirecting old version to new).
Related
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?
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:
Some WiX Quick Start Tips - chaotic, but
upvoted. Must have been helpful.
Helge Klein's real-world WiX sample - do check this out.
Rainer Stropek's WiX Samples on Github - can be very helpful.
From MSI to WiX by Alex Schevchuk - aging content, but excellent.
I've been investigation Quartz.Net and reviewing this question on StackOverflow, as well as the code base here
I've downloaded the Nuget Packages Quartz by Marko Lahma, v2.3.3, and it does not contain this the QuartzServer class, yet it exists in GitHub. I'm looking for a complete example using the features of Quartz.Net, as they are defined here, as this page is blank!
See response on "Quartz.Server is not included into Nuget package" issue:
Traditionally the server binary has been only part of the zip package and not in NuGet. So need to address this somehow before final v3.
Probably easiest to build yourself for now. Many want to customize the server any beyond the base template.
This is the error messsage I get.
I know it's kind of an eye roller, that it's difficult nigh impossible to tell what I may need without the source, but it seems like a deployment problem as people that installed the Qt SDK can run it. Plus, I figured I'd have better luck asking here than with a chinese developer that speaks google-english.
So here's what I've done:
I installed the MSVC2012.
I used a program called cffexplorer to see what the exe was looking for. I have the 7 or so .dlls that are at the top of the tree.
I found a recent (jun 2013) qwindows.dll from elsewhere on my system and put it in ./plugins (I've tried this file in ./, ./plugins, and ./plugins/platforms
I created a qt.conf with the following data (I determined the format from an existing Qt based app that works)
[Paths]
Plugins = plugins
Yet, I continue to get this message. Any suggestions on what I might look for to clear this up?
Ask the developer what compiler was used to build the application. Then you will need the right dll (that was built with the same compiler as the application). Also notice that (by default) the documentation says that qwindows.dll should be in the platforms folder in the same path as your executable, read more here. Depending on whether the developer used a Qt built with angle, you may also need: libEGL.dll and libGLESv2.dll. Dependency walker might help you find dependencies that are not there.
We have a client/server application which includes a Windows Service and a Winform client tool. I've managed to create a Wix project in Visual Studio (2010, using the wix 3.5 toolset). I'm using the "harvest" feature on the references instead of specifying every file, because there are many library projects involved.
Problems I'm trying to figure out:
How to include referenced DLLs? Some are in the GAC, some are in a relative path within the workspace. I assume I could list each file explicitly but it seems like there should be a way for Wix to autodetect them.
How to install the service while "harvest" is enabled. All the examples I've seen require adding an explicit element with KeyPath=true. However this doesn't work with the harvest=true setting.
I realize that the harvest functionality might be a convenience which is not feasible when there are more complex things going on. Should I give up on harvesting and just try to specify each file explicitly?
Most of the examples I've seen on Wix have been just snippets of xml files. Is there anywhere I can find complete real-world examples of installing services other non-trivial setup features?
Use WixEdit. http://wixedit.sourceforge.net/
It's very easy to import an entire folder using it.
Also, check out the great WiX tutorial here: http://www.tramontana.co.hu/wix/
5.4 Services Rendered
Services can be installed and started automatically.
http://wix.tramontana.co.hu/tutorial/net-and-net/services-rendered
For even more information, check out more WiX documentation here: http://wixtoolset.org/documentation/manual
does anybody know how to figure out the assembly versions (not file versions) of loaded assemblies if I have a full memory dump?
Suppose I have a full dump of the .net process and I found two assemblies with the same name loaded in one AppDomain. I need to know what versions those assemblies have.
The SOS commands !dumpmodule, !dumpassembly and !dumpdomain do not provide that kind of information or I just missed something.
Thank you in advance.
You could try the !SaveModule SOS command. This takes the start address of an assembly and creates a new file (the name of which is given by you) to save the contents of the assembly. You could then use something like .NET Refletor to open the file, and it might give you the .NET version somewhere in there. This SO question has some details on that:
How to find out which version of the .NET Framework an executable needs to run?
As for the !SaveModule command, here's a blog article that describes how to use it:
http://blogs.msdn.com/b/tess/archive/2006/05/18/601002.aspx?PageIndex=2