When creating a new deployment package (e.g. per http://msdn.microsoft.com/en-us/library/dd465323(v=vs.110).aspx) you're asked to provide a package location.
I'd like to append a timestamp to this filename, so that I can easily access older versions, just by browsing the output location.
i.e. I'd like to specify a value such as this: Packages\Test\MyProject{yyyy-mm-dd hh.mm.ss}.zip
...where the values in the braces are replaced by the current date/time.
Is this possible through native visual studio?
If so, how can it be done?
you can do that by editing your csproj file as follows (you have to open it as a text file):
- Near the end of the file you will find a comment with the targets AfterBuild and BeforeBuild, right after this comment add the following code
<Target Name="OnBeforePublishMyProject">
<PropertyGroup>
<_PackageTempDir>H:\Cs\Test\build.$([System.DateTime]::Now.ToString("yyyy.MM.dd.HH.mm.ss"))</_PackageTempDir>
<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>
</PropertyGroup>
</Target>
<Target Name="PublishMyProject" DependsOnTargets="Build;OnBeforePublishMyProject;PipelinePreDeployCopyAllFilesToOneFolder">
</Target>
Now you can Publish your project using the Visual Studio Command prompt and the following commands:
cd path_to_your_project
msbuild /t:PublishMyProject
You can create a bat file to execute those commands too
Related
I have some unit tests in my project that needs runsettings file to run properly.
When I launch those tests, I have issues with parameters that should be taken from the runsettings file
My question is how can I pass the runsettings file to visual studio code in order to use it when I execute my tests ?
Thank you in advance,
Regards
Two parts need file .runsettings when you work with VS Code:
when build tests in VS Code, it firstly run vstest.exe with parameters
when run tests in VS Code, it need mstest.exe.
For the first part, here is the document for .NET Core Test Explorer:
https://github.com/formulahendry/vscode-dotnet-test-explorer
The settings are available via File / Preferences / Settings. Navigate
to extensions and .NET Core test explorer.
Additional arguments that are added to the dotnet test command. These
can for instance be used to collect code coverage data
("/p:CollectCoverage=true /p:CoverletOutputFormat=lcov
/p:CoverletOutput=../../lcov.info") or pass test settings
("--settings:./myfilename.runSettings")
But above settings are global, you can setup from .vscode\workspace.code-workspace file for specified test project only:
{
"folders": [
{
"path": ".."
}
],
"settings": {
"dotnet-test-explorer.testArguments": "--settings .runsettings",
"dotnet-test-explorer.testProjectPath": "**/test.project.name.csproj"
}
}
For the second part, we need a new feature RunSettingsFilePath that's delivered from VS 2019 16.4.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<RunSettingsFilePath>$(MSBuildProjectDirectory)\.runsettings</RunSettingsFilePath> // or $(SolutionDir)
</PropertyGroup>
...
</Project>
If you're using the C# extension for VS Code, there's a setting to configure your .runsettings file. Go into VS Code's settings and search '.runsettings'. This should show the "Omnisharp: Test Run Setting" setting under the Extensions > C# configuration node.
I suggest clicking on the "Workspace" tab, so the setting is stored in your project instead of your user. That way, you can also check these settings into git.
I'm building a project locally using msbuild.exe like:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe MyProject.csproj
When I execute it through the Developer Command Prompt, everything works as expected.
However, when I execute it through the standard Command Prompt, I get an error saying:
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" was not found.
If I look up that folder path, I can indeed verify it's invalid (I only have VS 2015 installed on the machine).
So why isn't it working in Command Prompt, or conversely: why is it working in Developer Command Prompt?
Edit: The .csproj file is pretty much the Visual Studio 2015 default for an ASP.NET 4 website, and it specifies:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
To me it seems it would default to 10.0 if VisualStudioVersion isn't set, but judging from the error message it's assuming VS version 12.0.
I realize I could just modify the .csproj file, replacing 12 with 14, but I'd rather not go for a workaround, but instead understand why it's working in the Developer Command Prompt, but not the standard one.
I'm guessing it potentially has to do with different environment variables, or something along those lines?
When you run Developer Command Prompt you basically run VsDevCmd.bat from VisualStudio's Tools folder and sets some environment variables for the Console that you will be working with. Without those msbuild can't find correct file.
For example it sets VisualStudioVersion environment variable
#rem VisualStudioVersion
#rem -------------------
#set VisualStudioVersion=14.0
It depends on the .csproj but I suspect you might have something similar in it
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">12.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
So if the $(VisualStudioVersion) is not defined (and it won't in standard Command Prompt) it will use the version 12. And when you run it through Developer Command Prompt this gets set to 14 and you're good to go.
Hans Passant pointed me in the right direction in the comments, and typing where msbuild.exe in the Developer Command Prompt showed that it had two paths to MSBuild:
C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
The first one works in both the standard Command Prompt, and the Developer Command Prompt.
The second one (which my build script had retrieved from the registry) only works in Developer Command Prompt, probably explained by what Pawel said in his answer (essentially due to missing/different environment variables).
In my build script, I changed the registry path from...
HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\
to...
HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\
...and that produces the proper (current) MSBuild path in the build script.
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.
I currently have multiple projects being build using msbuild. I have a small customisation to the build that is handled by a .targets file. One solution is to add the snippet
<Import Project="MyTargets.targets"/>
to each project file. However, ideally I would like to not touch the project files, and be able to pass this information as a parameter to msbuild. That way I could easily control whether I run this customisation from the command line, and I don't have to touch the existing project files.
Is this possible?
You can do that easily with MSBuild 4.0 (check your version by top-level attribute ToolsVersion="4.0"):
There are multiple properties you can use to import your targets before and after Common.targets and or CSharp.targets loaded.
Simplest way is to use 2 sets of self explaining properties.
First set is:
$(CustomBeforeMicrosoftCommonTargets)
$(CustomAfterMicrosoftCommonTargets)
and second one:
$(CustomBeforeMicrosoftCSharpTargets)
$(CustomAfterMicrosoftCSharpTargets)
Property names are pretty self-explained.
Just pass full file name to any of this properties via msbuild.exe
e.g.
msbuild.exe /p:CustomBeforeMicrosoftCSharpTargets=c:\mytargets\custom.targets
You can use other "ImportByWildcard(Before|After)...." properties if you need to import multiple files. But in that case you need to pass more parameters to command-line.
Starting from MSBuild 15.0, the following two files are auto-imported into your build in case they are found on the project path or in any parent folder on the path to the root directory:
Directory.Build.props
Directory.Build.targets
Remark: once the props or targets file is found, MSBuild will stop looking for a parent one.
Also see: https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build
Lets say you have a project file called "Project.msbuild". You would add this conditional import:
<Import Project="$(TargetToImport)" Condition="'$(TargetToImport)' != ''" />
Then pass the name of the target file you want to import as an msbuild property:
msbuild.exe Project.msbuild /p:TargetToImport="TargetFile.Target"
Make sure you use an absolute path to the target file and it works.
Source: Sayed Ibrahim Hashimi - MSBuild how to execute a target after CoreCompile part 2.
msbuild.exe /p:CustomBeforeMicrosoftCSharpTargets="c:\mytargets\custom.targets" /preprocess:out.xml
Use /preprocess[:filepath] to see the result of the imports.
You don't have to modify any csproj or vbproj files.
Of course, it only works where you can set MSBuild Properties.
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.