I try to add a folder and its subfolders (~4000 files) as content to a C++ windows store app (in VS2015).
Heres the scenario:
G:\Game -> is the build directory
D:\data -> holds the original content
I've read there are some methods to declare external content in the .vxcproj file like that:
<ItemGroup>
<Content Include="D:\**">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<DeploymentContent>true</DeploymentContent>
</Content>
</ItemGroup>
This actually copies the contents of D:\data into the build-directory (G:\Game). This is great since the program can now be run & debugged. BUT: as soon as i deploy the project to the AppX Folder (G:\Game\AppX) the data-folder doesnt get deployed there.
G:\Game\game.exe
G:\Game\data\...
G:\Game\AppX
G:\Game\AppX\game.exe
(G:\Game\AppX\data\... - missing)
Any clues ?
After fiddling around for days, as of now i can state there is no way to do this properly in the Visual C++ - IDE (2012 / 2015) (it seemed to work with C# projects though).
The only way to achieve what i wanted to do is
a post-build-event using robocopy to copy/synch the data over to the AppX folder
Writing a script for the packaging / signing using MakeAppX.exe, SignTool.exe and 7-zip.
Related
I am using ClickOnce application deployment, and I just got my code certificate from Verisign. I am using this certificate to sign the manifest.
When I download and install the application, the smartscreen comes up with my name on it (lame, but I think this is what is supposed to happen). When the ClickOnce installer completes, the smartscreen comes up again for the execution of the actual application, here it says 'Unknown Publisher'.
Does ClickOnce not sign the assemblies by default? How do I do this?
Edit: Currently I am letting VS sign my manifest (installer) for the ClickOnce, and I am setting a Post-build event to sign my assembly. But still when I install the application it says 'unknown publisher' when I go to actually run it.
That does not sound right to me. I have used exactly the same workflow for multiple applications, and it works fine. Most likely there is an issue with your postbuild step. Make sure that you sign EXE file inside the OBJ folder (because that's where ClickOnce takes all the files from) - not the BIN one.
Do ClickOnce publishing, go to the OBJ folder, right click on your application.exe file, and select properties. It should have six tabs - the last one being "Digital Signature":
If you don't have it, you don't sign your application properly.
And here is my postbuild step - note that I sign "RELEASE" configuration only:
<Target Name="SignOutput" AfterTargets="CoreCompile" Condition="'$(ConfigurationName)'=='Release'">
<PropertyGroup>
<TimestampServerUrl>http://timestamp.verisign.com/scripts/timestamp.dll</TimestampServerUrl>
<ApplicationDescription>my app</ApplicationDescription>
<SigningCertificateCriteria>/n "my company."</SigningCertificateCriteria>
</PropertyGroup>
<ItemGroup>
<SignableFiles Include="$(ProjectDir)obj\$(ConfigurationName)\$(TargetName)$(TargetExt)" />
</ItemGroup>
<Exec Condition=" '$(ConfigurationName)'=='Release'" Command=""c:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe" sign $(SigningCertificateCriteria) /d "$(ApplicationDescription)" /t "$(TimestampServerUrl)" "%(SignableFiles.Identity)"" />
</Target>
To deploy to different azure environments I modify the csdef as part of the compilation step to change the host headers. Doing so requires building the cspkg once for each environment instead of being able to reuse the cspkg and specify different configs for deployment.
I would like to instead modify the csdef file of a cspkg after it has been created, without recompiling. Is that possible, and if so how?
I've done something similar to what you're after to differentiate between test and live environments. First of all you need to create a new .csdef file that you want to use for your alternate settings. This needs to be the complete file as we're just going to swap it out with the original one. Now we need to add this to the cloud project. Right click on the cloud project and select unload project. Right click on it again and select Edit [Name of project]. There's a section that looks a bit like this:
<ItemGroup>
<ServiceConfiguration Include="ServiceConfiguration.Test.cscfg" />
<ServiceDefinition Include="ServiceDefinition.csdef" />
<ServiceConfiguration Include="ServiceConfiguration.cscfg" />
</ItemGroup>
Add a new ServiceDefinition item that points to your newly created file. Now find the following line:
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" />
Then add this code block, editing the TargeProfile check to be the build configuration you're wanting to use for your alternate and ensuring that it points to your new .csdef file
<Target Name="AfterResolveServiceModel">
<!-- This should be run after it has figured out which definition file to use
but before it's done anything with it. This is all a bit hard coded, but
basically it should remove everything from the SourceServiceDefinition
item and replace it with the one we want if this is a build for test-->
<ItemGroup>
<!-- This is an interesting way of saying remove everything that is in me from me-->
<SourceServiceDefinition Remove="#(SourceServiceDefinition)" />
<TargetServiceDefinition Remove="#(TargetServiceDefinition)" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' == 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.Test.csdef" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' != 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.csdef" />
</ItemGroup>
<ItemGroup>
<TargetServiceDefinition Include="#(SourceServiceDefinition->'%(RecursiveDirectory)%(Filename).build%(Extension)')" />
</ItemGroup>
<Message Text="Source Service Definition Changed To Be: #(SourceServiceDefinition)" />
</Target>
To go back to normal, right click on the project and select Reload Project. Now when you build your project, depending on which configuration you use, it will use different .csdef files. It's worth noting that the settings editor in is not aware of your second .csdef file so if you add any new settings through the GUI you will need to add them manually to this alternate version.
If you would want to just have a different CSDEF then you can do it easily by using CSPACK command prompt directly as below:
Open command windows and locate the folder where you have your CSDEF/CSCFG and CSX folder related to your Windows Azure Project
Create multiple CSDEF depend on your minor changes
Be sure to have Windows Azure SDK in path to launch CS* commands
USE CSPACK command and pass parameters to use different CSDEF and Output CSPKG file something similar to as below:
cspack <ProjectName>\ServiceDefinitionOne.csdef /out:ProjectNameSame.csx /out:ProjectOne.cspkg /_AddMoreParams
cspack <ProjectName>\ServiceDefinitionTwo.csdef /out:ProjectNameSame.csx /out:ProjectTwo.cspkg /_AddMoreParams
More about CSPACK: http://msdn.microsoft.com/en-us/library/windowsazure/gg432988.aspx
As far as I know, you can't easily modify the .cspkg after it is created. I guess you probably technically could as the .cspkg is a zip file that follows a certain structure.
The question I'd ask is why? If it is to modify settings like VM role size (since that's defined in the .csdef file), then I think you have a couple of alternative approaches:
Create a seperate Windows Azure deployment project (.csproj) for each variation. Yes, I realize this can be a pain, but it does allow the Visual Studio tooling to work well. The minor pain may be worth it to have the easier to use tool support.
Run a configuration file transformation as part of the build process. Similiar to a web.config transform.
Personally, I go with the different .csproj approach. Mostly because I'm not a config file transformation ninja . . . yet. ;) This was the path of least resistance and it worked pretty well so far.
At the end of my Clean/Build, I wanted to always automatically copy the project folder into a zip for easy transfer. So I added this to my post build <target> in build.xml:
<zip zipfile="../project-xyz.zip" basedir=".." includes="project-xyz/**" excludes="*/dir/lib/**"/>
This works great on Windows, but on Linux, it removes any .hidden folders and all their children. I even tried
<zip zipfile="../project-xyz.zip" basedir=".." includes="project-xyz/**,project-xyz/.hidden/**" excludes="*/dir/lib/**"/>
and it still doesn't work.
What can I do to bring those files into the zip?
I am not opposed to detecting non-Windows environments and using <exec> on the zip command, though I am not sure how I would do that, and I am not sure I really want to, especially if there is a better way!
You can see what gets excluded by default from the zip by adding the following line in ant
<defaultexcludes echo="true"/>
And then use
<defaultexcludes add=.../>
and
<defaultexcludes remove=.../>
to customize what gets excluded by default.
Reference: Ant docs for DefaultExcludes
EDIT
You can also do
<zip defaultexcludes="no" .../>
Reference: Ant docs for Zip
I'm trying to get MSTest.exe to run, and it seems like testcontainer isn't being read properly; while my tests all run successfully in all config environments within Visual Studio.
the command I'm using is:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /nologo /usestderr /testSettings:"C:\temp\MyProject\Sources\MyProject\Local.testsettings" /searchpathroot:"C:\temp\MyProject\Binaries" /resultsfileroot:"C:\temp\MyProject\TestResults" /testcontainer:"C:\temp\MyProject\Binaries\MyProject.Services.Server.UnitTests.dll"
The project references within testcontainer project look like this:
<ItemGroup>
<ProjectReference Include="..\..\Services\MyProject.Services.Server\MyProject.Services.Server.csproj">
<Project>{92EC1999-CC0C-47DD-A4D6-17C3B1233C50}</Project>
<Name>MyProject.Services.Server</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Interfaces\MyProject.ServiceConfiguration.Interfaces.csproj">
<Project>{8E2E7BA9-75DB-458E-A184-AC1030EAD581}</Project>
<Name>MyProject.ServiceConfiguration.Interfaces</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Services\MyProject.ServiceConfiguration.Services.csproj">
<Project>{39514766-23A8-45DB-96EA-B6B4D9C8B086}</Project>
<Name>MyProject.ServiceConfiguration.Services</Name>
</ProjectReference>
</ItemGroup>
Neither the ServiceConfiguration.Interfaces nor the ServiceConfiguration.Services DLL is placed into the Out folder in TestResults.
The project GUIDs do match between the references and the referenced projects.
Is there something that I'm missing in the command line?
mstest.exe will not coy all referenced dll's.
See a blog post on this at https://web.archive.org/web/20111221110459/http://www.dotnetthoughts.net/2011/11/22/mstest-exe-does-not-deploy-all-items/
You can specify exactly what files are copied to the test directory using a test settings file. You can create multiple test settings files in Visual Studio, so you can have one for running from VS, another for running from MSTest, another for server CI builds, and so on. See here for more information: Create Test Settings to Run Automated Tests from Visual Studio
Use the /testsettings:<filename> option to specify it on the command line.
What seems to confuse people at first is that, by default, MSTest's "current directory" is not the MSTest launch directory, but the Out folder of the test results.
As mentioned previously, MSTest does not correctly infer all used assemblies, if you don't have a direct reference, it will not copy the assembly. That said, Visual Studio has similar behaviour in its build too, so a lot of people work around this by adding bogus code references - a terrible solution - I don't recommend it.
However, native DLLs are even more problematic, and I have found that explicitly copying them in the test configuration (test settings) works for them, just as for managed assemblies.
Whether it goes to Out or the build area depends on different factors, however, for the situations where it still doesn't work, you can use a DeploymentItem "hack", or, tweak your runsettings file.
Try looking at this answer: https://stackoverflow.com/a/33344573/2537017
I have just installed Microsoft Robotics Studio 2008 R2, and I must admit that I'm shocked to discover how paths are handled.
First of the studio wants to install itself into my personal profile (this is on Vista):
C:\Users\MyUserName\Microsoft Robotics Dev Studio 2008 R2
I assume this is because during development I have to write files to the robotics studio folder making C:\Program Files a no go.
Then when I create a new robotics project a lot of absolute paths pointing to the robotics studio is added to the project. If I check my project into source control and another developer checks it out onto his machine the absolute paths will not resolve and the project will not compile.
Also, since all services are collected into a single folder in the robotics studio folder developing multiple independent services on a single computer appears to be at least confusing.
Do you have any good strategies for handling this mess?
I have now figured out a way to change a Microsoft Robotics DSS Service visual studio project into something that you can compile and run in you own source tree independent of the installation path of the robotics studio. Here is a description of what you need to do to modify the project:
Add the robotics studio bin path to you PATH environment variable to be able to execute dssproxy.exe without supplying a full path. I have installed robotics studio into the program files folder to avoid accidentially writing files to the robotics studio folders.
Open the Properties page for the project and select the Build tab. In the Output section change the Output path to Debug\bin. For .NET projects it is customary to compile into folders bin\Debug and bin\Release but the robotics hosting service expects to live in a folder named bin and will store data in the folder above the bin folder.
Go to the Signing tab and select a new key in the Choose a strong name key file box. You can either generate your own key at that point or use the sn.exe utility to generate a new key. Or if you have your own policy for creating keys follow that. The sn.exe utility can be found in the tools folder of robotics studio.
In the Build Events tab edit Post-build event command line:
dssproxy.exe /dll:"$(TargetPath)" /proxyprojectpath:"$(ProjectDir)Proxy" /keyfile:"$(SolutionDir)Key.snk" $(ProxyDelaySign) $(CompactFrameworkProxyGen) /binpath:"." #(ReferencePath->'/referencepath:"%(RootDir)%(Directory) "', ' ')
Pay attention to the argument to /keyfile. Enter an expression that locates the strong name key file created in the previous step.
Copy the files DssHost.exe and DssHost.exe.config (or DssHost32.exe and DssHost32.exe.config for the 32 bit hosting service) from the robotics studio bin folder into the project folder and add these files to the project. Set the Build Action to Content and Copy to Output Directory to Copy if newer. Do the same for the manifest file for your service. Actually, the manifest file doesn't have to be in the same folder as the service, but copying it to the output folder enables you to do XCOPY deployment.
In the Debug tab change the Start external program to the DssHost.exe in the output folder of your project. You will have to build the project once to copy the file to the output folder. Clear the Working directory. Set the Command line arguments to
/p:50000 /t:50001 /m:DSSService1.manifest.xml
Change the manifest file name to the proper name in your project. You can modify the port numbers used either here or in the DssHost.exe.config file. If you are running in a protected Windows environment (UAC) you will have to use the httpreserve command to give yourself access to a particular port. You have to run this command as administrator.
Debug settings are not stored in the project file and each developer will have to create personal settings.
You should also update the Release configuration accordingly.
Since I was only interested in the CCR of MS Robotics, I just add these assemblies as a reference to any project I use it with and just be done with it.
This works without any problems. So if you are also only interested in the CCR and DSS part of the studio then this could be your solution
Reinier
we see this problem a lot. The absolute easiest solution is to specify the install directory when installing robotics studio to be "C:\program files\microsoft robotics studio". That way moving code between machines, checking out of source control, etc becomes a lot less problematic.
The other option is to use dssprojectmigration, which is included with RDS. Just run dssprojectmigration against your project directory, and it will correct all the hardcoded paths.