I've recently started using VSTS to build a Xamarin Forms App for iOS. I have it build using a hosted macos agent and then releasing it to a container in our Azure Blob Storage. The one thing I can solve at the moment, is how to include the Assembly Version in the name of the ipa file?
We're using an Enterprise license, so the ipa doesn't end up on any Store. At the moment I have the App_Name.ipa file and all previous versions App_Name.1.0.0.ipa in the container, however it's always App_Name.ipa that is downloaded.
I thought that it might be an option to parse the AssemblyInfor.cs file and extra the version and then set an environment variable - however I don't seem to be able to access the variable in the Release stage.
Ideally I'd like all this to stay is VSTS, however I don't mind trigger a WebJob to perform some extra tasks, however the version number doesn't appear to be accessible from the ipa file.
Can anyone suggest an approach?
You can use some related extension tasks to get Assembly Version from AssemblyInfor.cs files.
Such as you can use Assembly Info Reader task, and then you can get the Assembly Version by the variable $(AssemblyInfo.AssemblyVersion).
Related
I am working on a d365 unified interface sandbox environment on a development project.
This environment was setup recently as a clone of the production d365 instance.
Today I have been adding some plugins and finding a strange issue. I can get the plugin code on record create/update firing no problem (I have pre operation create/update and post operation create/update stages defined and the correct code gets hit for each).
But the C# plugin code does not recognise any of the pre or post images that I have added.
In code when we check IPluginExecutionContext.PostEntityImages it does not contain anything.
Any of the pre existing images that were there already when the environment was cloned are firing correctly. We have a process whereby we name all of our pre and post images the exact same for every entity and I know the ones I have created are named exactly as expected.
In this example I have created a Post Operation stage Update plugin on the OOB opportunity entity with a PreImage defined against it but the code just will not recognise it.
Anyone experienced this before?
TIA
Occasionally the sandbox service seems to fail picking up updates on a plugin assembly. In those cases updating the assembly with a different assembly version (build or revision number) can help.
If not, I would advise to simply remove the complete assembly and recreate it again.
If you do not have an automated deployment process in place, follow these steps:
Create a separate solution.
Add the assembly along with its step registrations and images to the solution.
Export the solution.
Remove the assembly using the plugin registration tool.
Import the solution again.
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.
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).
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.