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.
Related
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).
I am having a SharePoint site which is deployed through SharePoint powershell. the wsp is build through visual studio 2013.
All my projects in the solution are not Signed assemblies(project->right Click->properties->Signing->Sign the assemblies check box is unchecked). I am taking the wsp of my solution by publishing it and deploying it to the SharePoint using SharePoint powershell.
When I try to do this, I am getting the following error:
When I googled for the solution. Many of them are suggesting to Check the 'Sign the assemblies' check box. which I don't want to do, because I am facing some other issues with some packages install through Nugget.
Sign the Libraries of the Solution
Go to Properties of the Project then Click Signing tab and then Check the Sign the Libraries Options and create a new Strong Name file with or without password and then Rebuild and Deploy.
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 need to demonstrate a test version of my app. I DON'T want to load it to the store yet. I want create an installer of my app, so the user can go to my site and install the application by clicking.
First of all, have you read the documentation including developer installation, enterprise installation, publishing on the Web Store only to test accounts, and recent announcements of changes? Assuming you have, then with the exceptions listed in those sources, all apps/extensions must be published in CWS. They don't have to be listed publicly, but they do have to be published there.
Your best bet is to use the test-account feature of CWS for your demonstration.
This is very easy, yo can create the installer vía chrome://extensions > Developer Mode > Package extension.
Then you got the .crx file, you can upload it anywhere and share it. To install it, user must open chrome//extensions and drop the file in the page.
The option to install from webpage by clicking was disabled in Chrome for security reasons.
I've developed a WPF application. A large company is trying to make my application available to users' desktops. The traditional way to do this would be to point the users' browsers to:
http://www.MySite.com/MyApp.application
But the I.T. group at this company has configured their proxy server in such a way so as to block .application files for security reasons. They do, however, allow .exe files to pass through their proxy server and execute on client workstations. The irony of allowing .exe's from the Internet while blocking .application text files "for security reasons" isn't wasted on me but let's put that aside for a moment.
What kind of workaround would you recommend that would allow my app to launch from client desktops given that .EXEs are allowed? My first thought is to write a mini launcher app that does nothing more than download a .zip'd version of the .application file and all dependencies to a temp folder on the user's machine and then launch the .application file from there. Is there a better solution?
FWIW: Google has figured out a way to deploy their Chrome browser to Windows desktops in corporations like this one, despite the fact that ClickOnce is their deployment mechanism. If you view the source code at:
http://www.google.com/chrome/thankyou.html?&oneclickinstalled=
...you'll see they're pointing to an installer at:
/update2/installers/clickonce/GoogleInstaller_en.application.
That's a clickonce file. But somehow they've figured out a way to wrap it in an .exe in order to bypass proxy restrictions on .application files. I not familiar enough with JScript to understand what they're doing but it works. I'm trying to emulate this behavior for my own app.
This may not work for your situation. However, one possibility is to xcopy your exe and any dependencies to a folder on your webserver. Add a link in a webpage to your exe so your users can launch the app by clicking the link. In order for any of the users to be able to run the exe the first time, a caspol script needs to be run on each user machine to allow your app to run. Whenever you update the app, just xcopy the new version to the same folder on the webserver.