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
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.
How do you run Universal Windows (UWP) unit test projects from the command line?
I am using the MSTestFramework.
Short answer:
vstest.console.exe /Platform:x64 AppPackages\UnitTestProject1_1.0.0.0_x64_Debug_Test\UnitTestProject1_1.0.0.0_x64_Debug.appx
Long answer:
Create the project by selecting Universal / Unit Test App (Universal Windows) template:
Build it with command line using in the folder where the solution file is
msbuild /p:Platform=x64;Configuration=Debug
Try running the vstest.console.exe command above, in the short answer. It will fail, giving the following error message:
error 0x800B0109: The root certificate of the signature in the app package or bundle must be trusted..
For more details look into Event Viewer under Applications and Services Logs -> Microsoft -> Windows -> AppXDeployment-Server -> Microsoft-Windows-AppXDeploymentServer/Operational.
To be able to run tests from command line, you need to use a certificate which has trusted root, or make the certificate that generated by visual studio trusted. For the latter, double click UnitTestProject1_TemporaryKey.pfx file from windows explorer, and follow the import wizard default steps, but change two things:
Set Store Location to local machine:
Place the certificate to Trusted Root Certification Authorities store:
Finishing the wizard should say "The import was successful."
Try running vstest.console.exe using the parameters in the short answer, and now it should run all your tests.
I followed Ivan Marinov's answer, but I needed a purely command-line solution. Once you have your UWP Unit Test Project working and you are ready to automate, follow these steps :
(I named my solution Win10Universal and my unit test project Win10-UnitTests. You will need to substitute the names in my examples with your own)
Open Command Prompt as an administrator and navigate into the same directory as your solution.
Run MSBuild.exe on your solution.
>"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" Win10Universal.sln /p:Platform=x86;Configuration=Release
The build process will generate a directory similar to {SolutionDirectory}/AppPackages/{UnitTestTargetProjectName}/{Something_Test}. Navigate into this directory and inside you will see a .cer Security Certificate.
>cd AppPackages/Win10-UnitTests/Win10-UnitTests_1.1.0.0._x86_Test
Run CertMgr.exe on this generated certificate. This step will fail if you are not running Command Prompt with administrator privileges.
>"C:\Program Files (x86)\Windows Kits\10\bin\x86\certmgr.exe" -add Win10-UnitTests_1.1.0.0_x86_Release.cer -s -r localmachine root
Run VSTest.Console.exe on the .appx file in this directory.
>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" Win10-UnitTests_1.1.0.0_x86_Release.appx /Platform:x86
You should see your unit tests listed out in the window if you've done everything right! Hope this helps!
If both Ivan Marinov's and Kylaa's answers didn't work for you (like unfortunately happened to me), try using the appxrecipe of the UWP test app as the target file, and not the appx itself.
For example:
vstest.console.exe testProject.build.appxrecipe /platform:x64
https://github.com/Microsoft/vstest/issues/1393
https://github.com/Microsoft/vstest/issues/1477
Followed by #Marinov, UWP does not support to test the App currently. Only Library can be testable.
remarks: https://github.com/PrismLibrary/Prism/issues/140#issuecomment-165572951
So, if you want to do unit test in UWP, you have to pull your logic codes out from App project and pour them into newly created library project. Test project and original app project could be referenced afterwards.
I have test cases that are executable (*.exe files). There is no user interface involved.
How do I use Team center /visual studio online to run these test cases on server.
For now, either on demand running or scheduled running will work for me.
(Currently I have no test case that runs on server. So you may mention the basic setup. )
I have written some test cases (they are exe files). I can run them locally line any other exe file.
My code is in C++.
My test cases are in C++.
You could run them as part of your build. Just configure a build in VSO for your solution, and then modify the msbuild project file to call your tests and send the output to the build folder so it gets uploaded as part of the drop. If you are using VS, you would get a better experience using the VS unit testing support (i.e., get results in VS): http://www.visualstudio.com/get-started/run-tests-with-builds-vs.
I have eclipse and goclipse installed, all is well, I can run a console app in the IDE. It is possible to execute the unit tests in the IDE too?
The latest release of goclipse (0.7.6) does provide a means of doing testing using the "testing" package assuming you have followed the project structure recommended in C:/Go/doc/code.html in the installed file structure created when installing Go.
Using the Eclipse "run external tools" button create a new external tool configuration as follows:
on the Main tab the location is C:/Go/bin/go.exe
the argument is test
the working directory should point to the eclipse workspace folder containing the package that is to be tested (eg ${workspace_loc:/goProject/src/pnp}, where pnp is the name of the package NOT the name of the go file that contains the test).
You can now run the test by pressing the Run button in the usual manner, having given the configuration a sensible name eg: go test pnp. You can now add further tests to the package in different go files (or the same one) and all the tests will be carried out in a manner that is expected.
Yes it is if you make a makefile to do so... If you are asking if goclipse has a built in testing facility like JUnit for java the answer is no though.
The issue 5 was asking to "Integrate 'go test' into the IDE and developer workflow."
It now has just been closed (August 2015), with commit 9c3c858 (next release after 0.11.2), with the following documentation:
Each Go project has 3 built-in Build Targets, which are ways in how the project can be built.
These can be viewed and configured in the Project Explorer:
The modes are:
./... #build: The default build. Builds all Go packages present in the project (excluding test packages).
./... #build-tests: Builds all Go test packages present in the project.
./... #[run-tests]: Builds all and runs Go tests.
Each target can be enabled or disabled when for Eclipse project builds. (There is not much point to have both #build-tests and #[run-tests] enabled though.)
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.