i'm looking for a replacement of the Microsoft Federation Utility (FedUtil) from the WIF SDK, which allows me to automatically update (especially) the trustedIssuers list inside a web.config.
The old FedUtil could to this with /m /u as parameters.
Now the tool is included in VisualStudio and MS claims, there's no standalone replacement for FedUtil (refer to: http://msdn.microsoft.com/en-us/library/jj157089.aspx).
My question is:
Do i have to do the updates manually now or is there some command or tool to update the System.IdentityModel trusted Issuers automatically?
Since a tool seems not to exists which replaces FedUtils Update i made one on my own and published it to codeplex: IdentityModel.Tools
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.
We are trying to install a Java program to run as a windows service. Of the various available options(JSW, YAJSW, Launch4J, procrun, WinRun4J etc etc), we would like to use srvany.exe and install it using InstallShield. The Windows documentation says ...
Using RegEdit : create a "Parameters" key for your service (e.g. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MyService\Paramaters\ )
Using RegEdit : within the newly created "Parameters" key , create a string value called Application and enter the full path to the application you are wanting to run as a service.
Is there a way to achieve this using InstallShield without using InstallShield's registry editor? Is there an InstallScript call that can take care of adding and removing "Parameters" to the srvany entry in the registry? The solution should to work for Windows 2008R2 & 2003R2.
Any help will be greatly appreciated.
Assuming you are using a Basic MSI project type, I find a combination of the ServiceInstall, ServiceControl and Registry tables to be a good solution. Due to the fact that ServAny is really just a thunking layer, the ServiceInstall table can't fully describe the service without a little assistance from the Registry table. Still, no custom actions should be needed and the MSI will be very solid and robust.
As we were not able to find a favourable solution within available time, we decided to not use the srvany.exe. We decided to use YAJSW and within InstallShield use "Text File Changes" to modify the wrapper.conf for the YAJSW to launch our java application.
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
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).
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).