Using Visual Studio 2013 Update 3 running on Win 8.1, I have successfully built a signed APK by specifying values for key.store, key.alias, etc., in the res/cert/android/ant.properties file. Now I want to sign the APK with credentials retrieved from the native Windows crypto store -- i.e., pass -storetype Windows-MY to the jarsigner tool. How do I do this using MDHA?
After doing more research, I've concluded that the only way to do what I've described within the scope of the Android ant build is to somehow redefine the -release-sign target in ${sdk.dir}/tools/ant/build.xml. I say "somehow" because I can't figure out how to inject my own rules into bld/Release/platforms/android/custom_rules.xml.
On the other hand, I could write my own target in the MDHA project file to execute the jarsigner and zipalign tools. The downside of this approach is that it requires me to encode in the project file the locations of these tools and the target APK file.
Related
I created the MSI build package for our application. After this installation, we triggered another dependent driver software in the separate process in a committed event of Installer class like below,
Process.Start (" Path of driver software ")
We are facing an issue, installed directory ( It's empty ) folder is not removing while un-installing the same. Actually like installation, we triggered the un-installation of dependent driver software in the separate process by overriding the Uninstall method of installer class.
Anyone, please help me to overcome this issue? How could I remove the installed directory?
I can't change the installation procedure, since we are aware that we can't process another installation/un-installation when another one is going.
You are running a non-MSI driver install EXE from within your MSI? Correct? Or maybe it is an MSI wrapped in an EXE?
Do you have Installshield Premier? Could you use a suite project and install the EXE via the bootstrapper before (or after) the MSI install? I have honestly never used this feature, but running setups in sequence is what it is for. Embedded custom actions in MSI files kicking off EXE files are notoriously unreliable. This is - in my opinion - especially true if you are running with managed code as well (which I think you are).
In the long run managed code may yield safer custom action code (security-wise based on CAS), but for now it seems to cause unwanted runtime dependencies - especially for very large-scale distribution (global distribution) targeting diverse Windows versions (Vista, 7, 8, 10).
I am told it takes a while to get used to Installshield's suite feature, but maybe it is better for you? You can run EXE files, MSI files, patches and zips in sequence. Some fiddling to define uninstall and upgrade behavior I guess and lots of testing. I am pretty sure corporate application packagers would be happy to see a suite rather than an MSI with lots of strange stuff embedded in it.
UPDATE: Once you have compiled a suite setup.exe file it can be extracted as described here: Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file
Alternatively you could try to extract the setup.exe files for the driver setup and install the drivers as regular MSI components and run DPinst.exe to install / uninstall the drivers (tool from DIFx). Also quite clunky - especially when you need to include uninstall.
Your driver setup likely uses DPInst.exe already. I would check if you can extract an MSI from the EXE and use it instead of the EXE to include in the suite project. Some hints for how to deal with setup.exe files (extraction, runtime paramenters etc...): Extract MSI from EXE.
WiX has the Driver element in one of its extensions to deal with driver installs. I have never had the chance to test it.
I am developing a desktop application using QT Quick. I have been searching and reading the QT documentation (http://doc.qt.io/qtinstallerframework/ifw-tutorial.html) for creating an installer and how to use windeployqt.exe and binarycreator.exe to deploy on a windows machine. So far so good , but since I want to target this application for windows XP as well.
I want to know exactly what is required to be installed on the target machine to be able to run my application when using MinGW orMSVC2015 during building, so that I may include them in my installer or make the end user download them. Just like we download .Net Framework , Visual C++ Redistributable or DirectX when installing an application.
We use windeployqt to gather all the Qt official dependencis. Two parameters of windeployqt are quite useful:
--debug or --release: determine whether your app is in debug state or release state. windeployqt will put corresponding version of DLLs to your exe's directory;
--qml and put the directory of your QML files after it. windeployqt will search your given directory and put all the QML modules to your exe's directory.
2018-11-05 10:52:34:
It seems the second parameter --qml has been changed to --qmldir.
I need to create kind of builder for my Universal Windows App (UWP) application, that would load some configuration into it, build it and create app store package. Is there any way to build UWP app from command line, without associating it with the store and using Visual Studio at all?
There is WinAppDeployCmd, but it can be used to install builded appx package on device and I need tool like that to generate that package.
UPDATE
I've managed to build it and create app packages with command line, here is command I used:
msbuild "path to .csproj file" /p:OutDir=output_dir /p:AppxBundle=Always;AppxBundlePlatforms="x86|x64|ARM" /p:BuildAppxUploadPackageForUap=true
It's working but not as it should apparently. I can not install generated appx package on my phone (and emulator). I just get error
Failure reason: Failed to start deployment. Failure text: Install failed. Please contact your software vendor. (0x80073cf9)
I found many solutions for Windows 10 PC version, but there is only one solution I found for Windows 10 Mobile and this "solution" is to hard reset the phone, but I do not want to do that. Is there any other way?
And there is one more problem. This command doesn't work with parameter /p:Configuration=Release; and it only builds with Debug configuration, but I believe this is not related to previous error, because it doesn't work with Visual Studio either.
UPDATE
I could not find another solution, so I did the 'hard reset' of my phone and now it is working. It's sad, but I hope the reason is the Windows 10 Mobile OS is still in beta version.
Step 1 : See, you need to install .NET Framework installer from the below link. https://www.microsoft.com/en-us/download/details.aspx?id=30653
Step 2 : Go to C: drive and find where msbuild.exe is. You will find more msbuild. But mostly it will be in the location like C:\Windows\Microsoft.NET\Framework\v4.0.30319.
Step 3: Open the CMD in administrator and point to the location which is mentioned in Step 2.
Step 4 : Paste this. msbuild.exe "YourCompleteProjectPath.sln" /t:rebuild
See this for reference : https://msdn.microsoft.com/en-us/library/ms164311%28v=vs.85%29.aspx
I'm not a Windows 8 developer so excuse any stupid questions.
I have a Windows 8.1 application built in Visual Studio 2013 via a .sln file. This contains a number of projects: there is an application that relies on a library, this library (call it datalib) is built as a Windows Runtime Component (not a DLL);
there is also a test project which runs tests on 'datalib'
All of this works fine in VS2013, i.e. the tests execute.
I've been tasked with creating a TeamCity build for this so I've create a TeamCity build that builds against the sln file but I can't get the tests to execute (they're MSTest tests).
In my configuration I've added the test.dll (in the 'include assembly files list') but when I add this on it's own then I get a bunch of errors around references to types in the 'datalib'
The 'datalib' is built into datalib.winmd (I'm assuming this is the binary) so I thought that including this in the assembly list would fix my problem, but it doesn't.
I assume I'm missing something simple, what is it?
I'm now able to do this and it was a multi step process.
Firstly you don't load/test the winmd file directly you have to load the appx that's created by the test project 1; you can't use the MSTest runner that comes with TeamCity, instead you have to install the Visual Studio Test Runner plugin [2]; you have to run the build agent in an interactive process; and finally you have to install the root certificate that the application was signed with.
You reference the appx like you would a DLL
To install the build agent and have it run interactively it wasn't good enough to use the service and mark 'Interact with Desktop' you need to have full interaction so the agent has to be run from the desktop, as admin, at startup. To do this I had to create a scheduled task that run at startup and was given full privileges.
I installed the cert by running the ps1 file in the same directory as the appx file (Add-AppDevPackage.ps1) I'm sure this is overkill but it seemed like the easiest option at the time
[1] http://msdn.microsoft.com/en-us/library/hh691189.aspx
[2] https://confluence.jetbrains.com/display/TW/VSTest.Console+Runner
We have a TeamCity build server with a couple of agents set up to build code on check in for several c++ projects. Now, we've run into some problems regarding handling dependencies on Windows SDK since
It's to large to check-in and still be able to work with the source
smoothly.
Several can't be installed at the same time without problems.
The easiest way to set up TeamCity agents is to just install the Windows SDK. However, installing two versions the Windows SDK is problematic since it seems to overwrite registry entries of previous installations. Another approach is to cherry-pick files from the installation and put it on an rsync-server or the like, but the Windows SDK installer seems to modify Visual Studio binaries, etc so that does not feel good either. I've also checked with microsoft and they strongly suggested against cherry-picking files from the SDK install.
How have you set up your c++ projects on TeamCity and what would you suggest in our situation?
If you make sure the versions of the SDK are installed in the same location on each machine that you use (both developer and build machine) then you can add a step to the start of your build scripts which sets the current SDK for use. You can do this either:
Using the registry settings (if you have only one build going at any time)
Using environment variables, which you reference in your project files for lib, bin etc.
I've seen this work pretty well before, although we we weren't using TeamCity.