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
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 am new to Unity and i am try to understand plugins. I have got the difference between a managed plugin and a native plugin, but what is not very clear to me is:
what is the difference between a plugin and a dll? what should i expect to find in an sdk to make it usable in my unity project?
Thanks a lot
To expand on #Everts comment instead of just copying it into an answer, I'll go a little into details here
What is a plugin?
It's a somewhat vague word for a third-party library that is somehow integrated with the rest of your game. It means that it neither is officialy supported by Unity, nor is it a part of your core code. It can be "plugged" in or out without altering its internals, so it must provide some kind of API that can be used by the game code.
For example, you'll find many plugins that handle external services like ads, notifications, analytics etc. You'll also find a couple of developer-tools that can also be called plugins, like tile-based map editors and such.
Plugins come in many forms - DLL files are one example but some plugins actually provide full source code for easier use. And of course, other plugins will provide native code for different platforms, like Objective-C for iOS or .jars for Android.
So to answer your first question:
DLL is simply a pre-compiled source file that can be a part of a plugin
A plugin is a whole library that can consist of multiple files with different formats (.cs, .dll, .jar, .m etc)
What do you need to use an sdk?
First of all - documentation. Like I said before, and like you noticed yourself, not all plugins give you access to the source code. And unfortunately, not many sdks have extensive and developer-friendly documentations so it can be a tough task to actually understand how to use a given sdk.
Secondly - the code. Many sdks give you some kind of "drag & drop" library, a single folder with all the neccessary files inside that you simply add to your Unity projects. I've also seen sdks that use Unity packages that you have to import via Assets > Import Package > Custom Package.
Once you have the code and documentation it's time to integrate it with your game. I strongly recommend using an abstract lyer in your game as, in my experience, you often have to change sdks for various reasons and you don't want to rewrite your game logic every time. So I suggest encapsulating sdk-related code in a single class so that you have to change only one class in your code when switching from, say, one ad provider to another (and keep the old class in case you need to switch back).
So you basically need three things:
Documentation (either a readme file or an online documentation)
The code (precompiled or source)
A versatile integration
VS2013, MVC5, VB
I am nearing the completion of a small project to manage the roles tables in a standard MVC5 application. The code is pretty much encapsulated. What are my options for using this 'package' in other projects?
Can I compile it into something? I know this type of action is possible, I'm just not familiar with the options available to me or the steps to do this. Links to sites that have tutorials are fine. Is creating a Nu Get package the only way to go, or is that even in the ballpark of what I'm asking. I say Nu Get, but I don't mean for public consumption, only for my consumption.
Will the finished 'whatever' include it's controller class, view models and views? Will I be able to easily manage updates? etc.
Creating a Nuget package is one way. I have created a local repository of common utilities for this purpose. But I usually use it just for DLLs. I use Nuget Package Explorer for its ease of use since its just me using the packages most of the time. Not sure its possible to place the files in specific directories.
Files in the content folder are copied to the root of your application when the package is installed. - Nuget
The alternative is to create an item template. I used to use this method for class files I want in my code but I can't see why you couldn't do it for the rest. Works well and isn't too hard to set up. There are dozens if not 100s of tutorials on the subject. Here is one on code project.
I need to install a windows service using wix. Unfortunately ServiceInstall doesn't fit my needs. It doesn't allow to specify service file explicitly and needs to be placed into the same component where the service executable file is. But my components are dynamically generated by heat each time the project is build. So I can't put ServiceInstall there.
Does anyone know alternative ways to install the service?
The service is .net one so my first idea would be to run installutil from .net framework directly.
I've spoken at length of the many limitations of dynamic installation authoring. What I would do is statically author this component for the service (using ServiceInstall ) and exclude it from the dynamic generation process.
Then again, I don't use dynamic authoring period. I don't consider it a best practice.
You can transform the heat output with XSLT transform (see -t switch) the way you want. And it is still better than falling back to installutil... Take a look at the DTF documentation (DTF.chm installed with WiX, Development Guide > Managed CAs > InstallUtil) for the reasons why using installutil is not considered a good idea.
We register the capabilities of Delphi applications using TLB files. However, from reading MSDN documentation, "Installation package authors are strongly advised against using the TypeLib table. Instead, they should register type libraries by using the Registry table". Does anyone have any advice on how to do this in a 'Delphi' way for Windows 7?
It means you would need to figure out what registry entries to add to register the tlb. This explains what needs to be done. You could also use a tool like REGCAP.EXE which comes with Visual and generates a .reg file. If you use WiX to build your msi you could use tools like tallow and heat to let them generate the wix files for you.
I'm going to answer my own question! This is a duplicate of this question, which seems to have the answer I needed (just in a different language that I would normally use).