I've got a VSTO 3.0 Word addin that I'd like to profile using VSTS Profiler.
When I try to run an instrumenting run with the profiler, though, I get a warning that it can't be instrumented because the Addin DLL is signed, which, from what I know about VSTO, they have to be signed.
Is there any way to "turn off" the signature verification on Word VSTO addins?
Barring that, theoretically, I could NOT sign my addin, compile it, instrument it, and then delay sign it at the end of the build process, but I was hoping to avoid those kinds of hijinks with the project files.
Related
I have a Windows Form application that deploys using Microsoft Click-Once. I would like to add a new feature to the application that in part utilizes a third-party DLL that happens to be obfuscated. During an initial test release of the application, the application wouldn't install. Initial research seems to indicate that Microsoft Click-Once and Obfuscated DLLs don't play well together. Is that the case? If not, is there a special way to get an Obfuscated DLL to install/work in a Microsoft Click-Once deployment?
Thanks!
I'm developing a WPF application that I deploy with ClickOnce to a network share on the intranet from which clients can install it.
I need to make sure that the user can't modify any of the application files (especially DLLs and the main executable) on their machine. That is, if any of the application files have changed, the application should refuse to run. I was under the impression that, when using ClickOnce, this was available out of the box and that the application would refuse to start if the file hashes didn't match the manifest.
However, I tried to manually replace the executable or a DLL with a slightly different version after installation and the application still ran fine (executing the modified code).
Does ClickOnce provide what I'm looking for?
How can I enable the functionality?
I'm using a level 2 StartSSL code-signing certificate to sign the application manifest if this matters.
P.S.: just to be sure: I'm talking about the installed application files, not the installation files.
You can sign AND strong name each one of DLLs to prevent tampering but then, doing so has its own pain points when it comes to upgrades and distribution in general. Note that even doing so, doesn't entirely prevent someone from injecting code into your running process. It's a sticky subject.
I recommend going thru this question which already discusses these points in detail. Does code-signing without strong-naming leave your app open to abuse?
I think it will be a fairly manual process.
Doesn't look like the VS2013 deployment tools handle code obfuscation but they do support signing and app permissions. Start with that, then you might have to get the generated manifest as a starting point to build your own with obfuscated assemblies.
MS docs break it into 3 steps: 1. obfuscate, 2. build manifest, 3. manually publish
Here is what MS docs say...
Securing ClickOnce Applications
Deploying Obfuscated Assemblies
You might want to obfuscate your application by using Dotfuscator to prevent others from reverse engineering the code. However, assembly obfuscation is not integrated into the Visual Studio IDE or the ClickOnce deployment process. Therefore, you will have to perform the obfuscation outside of the deployment process, perhaps using a post-build step. After you build the project, you would perform the following steps manually, outside of Visual Studio:
Perform the obfuscation by using Dotfuscator.
Use Mage.exe or MageUI.exe to generate the ClickOnce manifests and sign them. For more information, see Mage.exe (Manifest Generation and Editing Tool) and MageUI.exe (Manifest Generation and Editing Tool, Graphical Client).
Manually publish (copy) the files to your deployment source location (Web server, UNC share, or CD-ROM).
Our Excel 2007 VSTO solution (built in Visual Studio 2010 SP1 using C# 3.5) is published via ClickOnce.
Clients deploy by clicking a URL using Internet Explorer that looks something like:
http://ourserver.com/ouraddin.vsto
It sometimes causes the Program Compatibility Wizard to pop up post-install and display "This program might not have installed correctly ..."
Does anybody know any workarounds?
I found this post which talks about modifying the manifest files, but that seems to apply to regular ClickOnce solutions not VSTO.
How to prevent "This program might not have installed correctly" messages on Vista
I tried using the MageUI app to open the VSTO file and look for a way to embed the supportedOS tags but there was nowhere to put it.
I also found documentation on editing VSTO manifests, but would prefer not going down this route unless absolutely necessary as one would think the publish wizard out of the box should just work.
http://codeidol.com/csharp/c-sharp-in-office/Deployment/Editing-Manifests/
Perhaps there is a way to modify the source VSTO ClickOnce schemas in the build system to avoid editing the manifests as a post-build task?
Any insight would be greatly appreciated!
Thanks,
Chris
I've successfully created a VSTO Add-In for Outlook 2007 in VS2010, yay! Now comes the deployment part, which seems to be even more arcane.
I need to deploy this Add-In on my company's server, which is running Windows Server Standard, SP2. It has MS Office 2007 on it, and the clients talk to a different Exchange server. The company has thin clients that all Remote-Desktop the Server to access their Outlook.
What would be the procedure for this? There's various articles that Google pulls up on deploying Office Add-Ins, all of which are a tad over my head. My impression is that there are many different ways to install Add-Ins, based on what Office version you have, what VS version you have, what OS you are installing it on, if you want to install for a single user or all users on the server, and various other circumstances. I can't get a clear picture of what to do. The fact that I'm installing on a system with a server/thin-client arrangement possibly complicates things.
Anyway, I can spend the next few days researching how registry keys work and how they affect Add-Ins, learning how to make .MSI packages, exactly how certificates work and if I need one to publish or if I can deploy into the Program Files directory, or if that option in the .NET 4.0 framework even applies to a VSTO Add-In, etc., etc., etc.
There's just a lot of variables and I would appreciate advice that pertains to my exact scenario. Or, barring that, exactly what subjects I need to study up on to know what to do, and links to them.
Edit: I need to deploy to 1 user on the server first, for testing, and then eventually all or most of the users, so help for singular and broad deployment would be appreciated.
The following articles helped me a lot when I first tried to deploy an add-in. Unfortunately my scenario did not included server/thin-clients, I used the MSI only for per-user installations, so I cannot say for sure what will be the complicates to rise from the side.
Here is the article:
http://msdn.microsoft.com/en-us/vsto/ff937654.aspx
There you should find all the info required for registry location, files, manifests, etc...
I have a smart client app (WinForms/WPF) currently deployed using ClickOnce.
A particular client has expressed the desire to silently deploy the app to it's intranet network users as part of its nightly/weekly client PC update service - presumably via MS Systems Management Server (SMS) and Group Policy or similar (I don't understand the exact mechanisms). As such, they've requested a .MSI installer instead.
So a few questions for confirmation (along with my thoughts on answer - am more than happy to be wrong!):
Can a ClickOnce app be silently installed en-mass by admin???
My thoughts: No, because ClickOnce is a per-user installation this would be difficult unless the user is actually logged in at time of remote installation.
Is there a tool to convert a ClickOnce app/project's settings to a simple MSI installer project (e.g. Visual Studio Deployment Project)???
My thoughts: Not in the box, but would love a tool to repeatedly copy/use settings from the ClickOnce config to the deployment project - e.g. ProductName, Version, File Associations etc. This way we only maintain one set of deployment settings.
Any other alternatives for this scenario to get 'er done quick...?
I don't think you can install a ClickOnce application silently, certainly not with SMS. And I don't know of any tool that does that, but it doesn't mean it doesn't exist. ;-)
The idea of deploying a shortcut is an interesting thought. Have you ever noticed that if you leave a shortcut on the desktop even after the application is uninstalled, if the user clicks on it, it reinstalls the application?