There was a challenging situation happened when i was working with install to provide product key validation. I had to use C++ unmanaged code to validate the key. Actually we had the main validation logic written in C# and I had to create a mixed project. Problem was not stopped only with these, it continued. Since I used VC++ code, it expected atleast the VC++ runtime redistributable to be installed in the client machine. I thought of dropping the plan to migrate our install to Wix because of these kind of problems.
But I came to know that there is a nice and very cool feature that DTF is available in Wix to integrate any kind of actions in C#. I used it and could integrate the key validation in couple of hours and till now it is working fine in all client machine I implemented before 6 month.
Do you have any interesting moment or nice experience with DTF?
Search my blog at http://blog.deploymentengineering.com for DTF and you'll find a lot of useful content. I love DTF but I still believe that the best solution is to avoid a CA whenever possible in the first place. C#, like VBScript before it, is so luring that it tends to suck imperative thinking developers into writing CAs when not needed. I believe this is the reason DTF wasn't released for so long.
At my day job my approval is required for anyone who believes they need a CA. I instruct the developers on basic MSI philosphy, how to use DTF, how to attach a debugger and I make it clear that they are on the hook if it ever has any issues. The result is very few but well written CAs in our product line.
I have written several .NET CAs to support our WiX based installs:
Managed Wrapper around HTTPAPI.DLL - supports creating IP/Port SSL bindings and HTTP Url ACLs for use in deploying WCF services. I plan to turn this one into a Wix Extension. It was very interesting learning how to properly handle rollbacks, etc.
SSL Picker dialog that displays all the SSL certificates on the system and allows you to pick one.
SQL Server browser dialog - lets you browse your network for SQL Servers and then browse SQL Servers for Databases. Optionally uses impersonation. This is for crafting a connection string.
I am in the process of writing a set of CAs that will use the Microsoft.Web.Administration assembly to do native installs of web applications on IIS 7 (without requiring the IIS 6 Metabase Compatibilty feature be installed).
First off, the C#/DTF custom actions are still custom actions (no magic here :-)), so you should follow all the various CA guidelines working with this kind as well. It simplifies most of MSI tasks by abstracting low-level API behind the high level well-designed classes. Also, keep in mind that you can use managed code CA only in case the target machine has .NET installed (or install it as a prerequisite). Finally, the dtf.chm documentation which is distributed along with WiX toolset has some simple, but self-explanatory examples.
Hope this helps.
Related
I currently spike with WiX 3.11.2 to build a burn bootstrapping application that downloads packages from a local http server currently without any authentication.
Due to a lack of documentation of WiX burn I mostly reverse engineered how to set the UpdateLocation + how to check for updates via skimming through the UpdateViewModel.cs from the Wix3 repository.
As far as I have read, the
Engine.SetDownloadSource(ea.PackageOrContainerId,ea.PayloadId, dlUrl,user,pass);
can be used to download with no AUTH (last 2 parameters null) or plain authentication. Without authentication I already have a working prototype - but I will need the possibility to authenticate against a OAUTH secured web server.
If I were to need for instance to download behind a OAUTH2 authentication would the best practice be to use the OnResolveSourdce Event and instead of setting the Result to Result.Download, just do it myself with OAUTH2 libraries and download it to the ea.LocalSource so the engine basically thinks that the source has always been already available?
My second question is with regards to the UpdateLocation.
In the OnDetectUpdateBegin event I can set the ea.Result to Result.Ok if I want to check for upates - but I would like to be able to change the UpdateLocation during runtime, similar to what the Visual Studio Installer allows - to have different ReleaseFeeds, something like PROD or TESTING or Preview.
is there any possiblity to tell the Engine to set the UpdateLocation to a different URI? It would seem that the OnDetectUpdateBegin event would be perfect to change that, but the ea.UpdateLocation only has a Get, and I did not find a Engine.SetUpdate location or anything similar.
If I am not mistaken the VStudio installer is also built upon WiX so I would presume it should be somehow possible - am I missing something here?
I have a "proof of concept" piece of work that crosses over into some unfamiliar territory. I have some experience on J2EE technologies. I'm tasked with connecting an EFTPOS machine to an web application. I am planning to use applet to interact with dll. dll will be running on the client side.
I need to interact with one dll from web application. Please provide me any guidance on this, as I am new to it. I tried interacting with dll from standalone java program, but not able to connect from web application. Any sample codes will be very helpful for me.
Yes that is perfectly possible with an applet. I "connected" an electronice signing device before and it was working very well. Depening on what kind of .dll we are talking about here you need to do the following things:
1.) Create a java access layer / interface for your dll, so that you are able to call the dll functions from java. Depending what kind of dll we are talking about there are several possibilities. The base technology is JNI which is however quite cumbersome to use but luckily there are much more convienient ways out there:
use JNA (if it is a C dll)
use Jacob (if it is a COM component)
use bridj (if it is a c++ dll. You may try swig but haven't used that, so can't tell)
2.) Put your dll inside a jar file and distribute it alongside your applet. How this works is quite nicely described in the jacob project which provides an example for that. You can find it in the source package under jacob-1.17_src.zip\jacob-1.17\samples\com\jacob\samples\applet The example describes the JNLP way to access a native library which will work above java version 1.6.0_10. If you have to use a lower version for some reason, it is also possible but is slightly more tricky...
3.) One more side note: Since the latest available java version (1.7.0_51 or 1.6.0_71) due to security, some rules have been added or tightened for java applets. Now you have to sign your applet with an official certificate and set the right attributes/properties in the manifest, jnlp files. But this has been discussed in great detail here so just search for it. I would probably use a slightly older version for development and if that is working, figuring out how to make it work in the latest java version...
4.) Regarding the interaction part there are also several possibilities. Your Java Applet can call jscript methods from the website it is running in (or also the other way around) or the applet directly communicates with your server. You have all possibilities on that front...
So I have this bit of a project planned for Windows Store and Android. Basically, a networking multi-tool coupled with a scripting engine to implement protocols and behavior. Ideal uses being things like "my embedded device uses this simplistic network protocol. I'd like to quickly prototype a way to control it from my tablet".
It's my understanding that the Android market should have no problem with this. However, the Windows Store policy includes a vague clause concerning remote code execution
3.9 All app logic must originate from, and reside in, your app package Your app must not attempt to change or extend the packaged content
through any form of dynamic inclusion of code or data that changes how
the application interacts with the Windows Runtime, or behaves with
regard to Store policy. It is not permissible, for example, to
download a remote script and subsequently execute that script in the
local context of your app package.
Of course, the scripting engine will be sandboxed and such and should be "safe"(completely intepreted, no reflection), but does it violate this policy?
If you build in your scripting engine, and only run local scripts, you will be good. However, if you were thinking to have a repository of scripts that could be downloaded and subsequently run, that would be in violation of the policy as we understand it.
Unfortunately I don't think anyone but someone on that team can answer that (or someone with direct experience in that) because of the closeness to the legal language. Have you tried the Windows Store Appl Publishing forum at: http://social.msdn.microsoft.com/Forums/en-US/windowsstore/threads
In the context of scripting engine example given, unless the app modifies the scripting engine after deployment on user's system such that the representation of protocol/behavior (the script artifact's format) is made to change then it'll be policy violation. Its as if you submit Python interpreter, and at some point in time it abruptly moves onto interpreting ecmascript.
I am trying to deploy some MVC4 web apps with secure bindings on Windows Server 2008R2 and WiX 3.6 (stable)
I am desperately trying to get this to work without resorting to writing a follow-up powershell script or my own custom action.
The WiX iis:Certificate extension wants to install the certificate for me first before I can use it. That's not going to work in a production environment. The certificate is not going to be available to the installer at any time in .cer or .pfx form. It will already be deployed on the target machine in the localMachine/my store where you'd normally go when installing manually with the IIS7 snap-in. I will want the installer to be able to reference it by supplying any of the following: thumbprint, Friendly id or perhaps find it matching the web site host header binding pattern.
Is there any way of referencing a pre-installed certificate in WiX script without having the original .pfx file and password at build time or install time? (I got these last two scenarios working fine in test, but it isn't what the client wants).
Thanks.
I had a similar requirement to you so I wrote a post about it:
http://manyrootsofallevilrants.blogspot.co.uk/2013/07/assign-certificate-set-https-binding.html
Well it's been a while since I posted this.
Since then, I got on with it and wrote a custom action in C# to do the heavy lifting. Powershell didn't seem to give me the control of failure modes that I needed.
I can't post the code - since it belongs to my client, but I can say that I used Microsoft.Web.Administration in a similar way to that described in this question: Programatically Import Cert Into IIS. I hope that helps. It wasn't the answer I wanted, but it did solve the problem.
I'm working on a new feature for our product, a component of which has some fairly major security implications: it runs as a WCF service, and performs some highly-privileged actions. As such, I'd like that component to only be installed when the user requires it (and removed when it's no longer required), and for the installation to be accomplished programmatically.
I've looked into advertising (specifically, assigned installs), and it appears to be a good mechanism for accomplishing this. I'm not sure whether the installation of an advertised feature can be undone, however, which would be useful for removing the component when it's no longer required. I'm also not completely sure whether programmatic installation could be achieved with advertising: advertised COM classes seems to be discouraged.
I'm wondering, therefore, if a simple call out to msiexec to install/remove the component would be more sensible. The component could be packaged in a separate MSI, or as a separate feature of our main MSI.
What techniques have you used for installing features on demand?
I resolved this by installing all the necessary bits and pieces up front and then starting/disabling the WCF Service as required.