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!
Related
I'm using AppVeyor CI to build my UWP app and want to create an APPX package during every build. However my .gitignore is ignoring the Package.StoreAssociation.xml and MyAppName_StoreKey.pfx which I want to include in the APPX package as they are identifying my app in Windows Store.
Is there any way to get these files using PowerShell or MSBuild or something like that? In other words, is there any command line equivalent to the Project > Store > Associate App with the Store... wizard?
I know I can upload these files to the repo as Secure files but I'd prefer getting the latest files from the Dev Center with every build.
I would say probably not, as the Associate App with the Store Wizard, is an authenticated Wizard which requires a users Microsoft Account to be registered with Visual Studio, Load Credentials from storage or asking for OAuth, and then Visual Studio goes to Microsoft's server to Sign the Certificate and Sign the app with it.
AppVeyor documentation says the currently UWP is not officially supported for UWP, as a Microsoft License is required.
Edit: Does this help?
Is there any way to get these files using PowerShell or MSBuild or something like that? In other words, is there any command line equivalent to the Project > Store > Associate App with the Store... wizard?
No, as #William's explanation. The associating operation needs user's interaction in Visual Studio, this doesn't depend on a public command/API.
In my experience, we need to store(maintain) the latest store association information in somewhere, overwrite the related files and replace the reserved keywords in the app's manifest template file before packaging.
I've switched to using Visual Studio Code and and am missing the ability to right-click and publish files.
I read here that a task runner can be used to build/deploy files...
Publish Web Deploy using VS Code
That answer only mentions Grunt and I cannot find any articles on how to do this with Gulp which I am already using. I've got as far as finding an article on how to hook up Gulp and MSbuild which I assume must be the first step.
However, I'm unsure about the deployment step as I don't know what the "publish" button in standard VS does. It seems to be using something called MSDeploy or "web deploy" and requires a bunch of publish settings, so presumably this can be done from gulp?
I know I must sound a bit clueless but I'm not really a Microsoft guy I'm a front-ender, just happen to be working with other people's .net projects occasionally. Any help would really be appreciated.
WebDeploy is the technology that VisualStudio uses for web deployments. WebDeploy uses MSDeploy behind the scenes. MSDeploy is capable of far more than just web app deployments. We use it for deploying Windows Services, Scheduled Tasks and SQL databases as well.
Here are details on you to use the MSDeploy commandline. The sync command is used most commonly for deployments.
You can use the gulp-mswebdeploy-package plugin to create a web deploy package as part of you gulp build task. you can the use the msdeploy command line to deploy the site.
In setting up Sitecore 7.2 at my organization for our public facing .com I have run into a hiccup while trying to implement proper CI, Release Management, and Deployment Management. I am able to, using MSBuild, compile my Sitecore MVC code, compile .update packages from TDS, and package each of these in .nupkg files for Octopus Deploy. What I am running in to is that once I have deployed the MVC code I must also deploy the Sitecore Structure/Content which requires me to install .update packages. I have tried the solution provided at https://github.com/adoprog/Sitecore-Deployment-Helpers but for a fairly lightweight site this is timing out around 20 minutes within Octopus Deploy for only my System package, let alone having not touched Structure or Content. I am looking for a way, preferably through PowerShell (not strictly speaking, the Sitecore PowerShell Extensions built into the sitecore web interface after installing that package). Using the SPE would be acceptable if, and only if, I can use SPE's Cmdlets from Octopus Deploy's PowerShell workflow.
Please Advise.
Jason Bert has a great series of blogs on using Octopus Deploy with TeamCity and TDS for deploying to Sitecore instances:
http://www.jasonbert.com/2013/11/03/continuous-integration-deployment-with-sitecore/
You can also use TDS itself to deploy the items in the solution, but this uses direct calls to a webservice on the target Sitecore instance which may not meet with your requirements.
Also, are you deploying the entire System tree? 20 minutes to deploy changes made to the System tree seems unusual, unless you've made a LOT of changes in there (for example, the Dictionary). Even then, you shouldn't be source-controlling author content, only the elements crucial to the solution that are owned by development.
You can install the update package via sitecore utility at /sitecore/admin/UpdateInstallationWizard.aspx
If you experience that installing the package via this mode takes a lot of time, you might want to modify the Deployment Property Manager settings for the TDS project.
You can do this by right clicking your TDS project in Visual Studio and selecting "Deployment Property Manager".
Once the Deployment Property Manager window opens up, set the Deploy property to Once for every node which does not need to be updated. For any items which are to be updated, mark them as Always.
This will drastically save you on the time required to install the package.
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).
I'm undecided about CRM at the moment. It's a great tool for the business users but so far for development it's been a bit against the grain. The next problem I need to tackle is how to easily source control javascript used within forms. We use TFS for our source control.
Anyone had an experience or have any ideas on how to do this?
Obvious choice would be to copy and paste the JS in to your source control, but it's also an obvious pain in the rear.
A couple of things that we do in our projects:
We use the Web Resource Utility included with the CRM SDK (actually a modified version of it) to deploy JavaScript web resources to a particular solution. Makes it very easy to keep script files checked in to source control as normal and avoid copying and pasting.
We wrote a custom HTTP Module that we use on local deployments. It intercepts requests for JavaScript libraries and redirects them to a location on local disk. That way, we don't have to actually redeploy the web resources as we test, just the JavaScript files to disk. (Note that this would be unsupported in a production environment. We just do it in our development environments to ease the pain of JavaScript deployment).
I answered a very similar question here - Version Control for Visual Studio projects and MS Dynamics CRM (javascript)
My choice for source control is TFS holding each of the 2011 JScript libraries.
We try to mirror the file structure that Dynamics uses for Web resources in a basic Library project. So version control works as normal, we just don't use the output from the project.
You can also try using the new "CRM Solution" project template (installed from the SDK) and have the ability to deploy from the context menu of the project.
I've had some issues with the template but something to check out.
Hope this helps.
You can take a look on my answer on my own question here.
MS Dynamics CRM 2011 SDK has solutionpackager.exe utility what could split all CRM resources into file tree and you can store them either in git or in tfs.
Any web resource in CRM 2011 is a pain to manage. We just end up doing a lot of copy pasting in and out of TFS 2010 (which has actually caused some problems with poor pastes).
Currently out of the box there isn't an easy way to do it.
Only worry about this if you really need the ability to go back to old versions of web resources. I've found that I don't often have to do this. Remember that the web resources are stored in SQL Server just like they would be if you put them in TFS, so as long as your CRM database is being backed up, you won't lose the web resources. In traditional development, it is important to keep the source in TFS because you can't easily get back to it once you compile and release. With CRM development, your web resources are mostly HTML or JavaScript, so you can always get at the source.
If you really need version control, why not build a quick little console app that downloads all customizations every night and stores that zip file in TFS? True, it wouldn't be as easy to get at older versions, but you should gain a lot of productivity by not having to manually keep TFS in sync. This also has the benefit of storing all customizations in TFS, not just web resources.
Silverlight is the obvious exception here - I would definitely store Silverlight web resource source code in TFS, because it is a "compiled" web resource. You are already in Visual Studio, so TFS is a natural fit anyway.
Hope that helps!