Get TFS ChangeSet in running application - visual-studio

I have searched over the net for about 2 day now for this. Maybe i dont use the right terms. What i wish to do is to compile my project with the current TFS ChangeSet varriable avaliable. I'm not using TFS Build.
The only thing i have try, without success, is to use MSBuild Task with MSBuild Extension Pack to get the current ChangeSet(Not only the and put it into the assembly version(Revision). It fail because i dont use Build ... Here is the sample i have try
It's the first time i use this "Task" kind of programming and i dont know if i can do this without setuping TFS Builds. I can't setup Builds because i use external dlls and projects, wish seem to be complicated to setup.
(My next step is to check more about TFS Builds) ...
The raison i need this value at runtime, it's because i need this value in our error report feature. I wish to make this process automatic to avoid errors.
(Visual studio 2013, TFS [VisualStudio.com], Asp.net MVC 5)
Solution:
Tanks to Giulio Vian
This get the TFS ChangeSet of the current solution, not the newest, and write it in a file "TFS.cs".
the output file look like this:
static class TFS { public static string ChangeSet { get { return "436"; }}}
i have created a file "TFS.targets" into the root of my project:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!--
add this line to Target to run this only on Release:
Condition="'$(Configuration)' == 'Release'" -->
<Target Name="BeforeBuild" >
<!-- Get information on the latest build -->
<Message Importance="High" Text="Getting TFS Chanset"/>
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\tf.exe" info "$(SolutionPath)" | FIND "Changeset"" ConsoleToMSBuild="true">
<Output TaskParameter="ConsoleOutput" PropertyName="ChangesetLine" />
</Exec>
<PropertyGroup>
<ChangesetNumber>$(ChangesetLine.Substring(13, $([MSBuild]::Subtract( $(ChangesetLine.IndexOf(';')) , 13 ))))</ChangesetNumber>
</PropertyGroup>
<Message Importance="High" Text="ChangeSet: '$(ChangesetNumber)'. Writing TFS.cs ..."/>
<Exec Command="echo static class TFS { public static string ChangeSet { get { return "$(ChangesetNumber)"; }}} > TFS.cs" Outputs="TFS.cs">
<!--Add this file to the list to compile-->
<!--<Output ItemName="Compile" TaskParameter="Outputs" />-->
</Exec>
</Target>
</Project>
Then i have edited the project file and added this line in the Project node:
<Import Project="$(MSBuildProjectDirectory)\TFS.targets"/>
(Search for "Import Project" you will find some in your project)
on the first build, the file will not be in your project. So include it to use it. (Show all files).
if you wish to include it in the version, replace the exec echo by the code in this question but you will need to install MSBuildCommunityTasks
An other update
After some testing, it seem it dont show the last ChangeSet for the directory/solution. the correct command is
tf history "c:\YourSolutionDir" /noprompt /recursive /stopafter:1
the problem with this is it give you a response who is hard to extract with MsBuild.
i have writed an console application who will return only the changeset:
static void Main(string[] args)
{
Process p = new Process();
// Redirect the output stream of the child process.
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.FileName = #"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\tf.exe";
p.StartInfo.Arguments = "history \"" + args[0] + "\" /noprompt /recursive /stopafter:1";
p.Start();
// Do not wait for the child process to exit before
// reading to the end of its redirected stream.
// p.WaitForExit();
// Read the output stream first and then wait.
string output = p.StandardOutput.ReadToEnd();
p.WaitForExit();
var lines = output.Split(Environment.NewLine.ToArray(), StringSplitOptions.RemoveEmptyEntries);
var last = lines.Last();
var s = last.Split(' ');
Console.WriteLine(s[0]);
}

You can call the tf command to get information about TFVC files and folders. By running the tf info command in a local directory mapped to a workspace, you get lot of useful data, e.g.
Local information:
Local path : D:\Workspaces\xyz\mine.sln
Server path: $/DefaultCollection/xyz/mine.sln
Changeset : 6611
Change : none
Type : file
Server information:
Server path : $/DefaultCollection/xyz/mine.sln
Changeset : 6611
Deletion ID : 0
Lock : none
Lock owner :
Last modified: Saturday, March 14, 2015 09:38:44
Type : file
File type : utf-8
Size : 1994
Embedding the command in an MSBuild file is not hard as the following snippet shows
<Exec Command="tf info "$(myChangesSetReferenceFile)" | FIND "Changeset"" ConsoleToMSBuild="true">
<Output TaskParameter="ConsoleOutput" PropertyName="ChangesetLine" />
</Exec>
<PropertyGroup>
<ChangesetNumber>$(ChangesetLine.Substring(13, $([MSBuild]::Subtract( $(ChangesetLine.IndexOf(';')) , 13 ))))</ChangesetNumber>
</PropertyGroup>
The tf command comes installed with Team Explorer.

The TeamBuild task can only retrieve ChangeSets for a TFS build. You said you aren't using TFS builds yet so that won't work.
You could use the TFS API to pull changesets from TFS.
Honestly though that will be more difficult than just using the TFS build system if you were going to go to that anyways.

Related

Visual Studio constantly triggers MSBuild Targets

I want to execute a text template before my MSBuild project in Visual Studio. I have added the following to my project file:
<Target Name="TransformOnBuild" BeforeTargets="ResolveProjectReferences">
<PropertyGroup>
<_TransformExe>$(MSBuildExtensionsPath)\..\Common7\IDE\TextTransform.exe</_TransformExe>
<_TextTransform>$(ProjectDir)AssemblyInfo.tt</_TextTransform>
<_TextTransformResult>$(ProjectDir)AssemblyInfo.cs</_TextTransformResult>
</PropertyGroup>
<Exec Command="del "$(_TextTransformResult)"" />
<Exec Command=""$(_TransformExe)" "$(_TextTransform)" -out "$(_TextTransformResult)"" />
</Target>
This simply deletes my AssemblyInfo.cs and regenerates it from AssemblyInfo.tt.
I use BeforeTargets="ResolveProjectReferences" because I need this file regenerated before any of the referenced projects get built.
Basically, this already works but I have noticed something strange: When I have this in my project file while Visual Studio is open, the AssemblyInfo.cs file constantly dissappears and then reappears. To me it looks like VS repeatedly executes my build target in the background. Of course I don't want it to behave like this. I want it to regenerate the file only when I start a build.
Is there any way to achieve my goal without generating constant CPU load and annoying file-wobbling in the explorer? Maybe a different base target than ResolveProjectReferences?
I use Visual Studio Professional 2022, Version 17.2.6
Update based on latest comments.
You could also try Condition="'$(DesignTimeBuild)' != 'true'".
Details/Background.
If you can live withit never being run inside Visual Studio, you can add this condition to the target element:
Condition="'$(BuildingInsideVisualStudio)' != 'true'"
Otherwise you can try this:
<Target Name="TransformOnBuild" BeforeTargets="ResolveProjectReferences"
Inputs="$(MSBuildProjectDirectory)AssemblyInfo.tt"
Outputs="$(MSBuildProjectDirectory)AssemblyInfo.cs">
<PropertyGroup>
<!-- ... -->
</Target>
You can learn more about Inputs/Outputs here. Basically, in this case, it means that the target will only be run, when AssemblyInfo.tt is newer than AssemblyInfo.cs.
Note that VS (for intellisence, etc.) will run targets in the background.

Determine whether it's a build or rebuild in .cmd script called in prelink step inside Visual Studio

How can a .cmd script run from within a Visual Studio (2005, 2008, 2010, 2012 and 2013 respectively) project's pre-link stage determine whether this is a full rebuild (Build.RebuildSolution/Build.RebuildOnlyProject) or "ordinary" build (Build.BuildSolution/Build.BuildOnlyProject)?
This is an external script (LuaJIT, if you must know) and I don't want to rebuild the library every single build of the project. Instead I'd like to limit the complete rebuild to situations where I choose exactly that option.
How can a .cmd script run from within a Visual Studio (2005, 2008, 2010, 2012 and 2013 respectively) project's pre-link stage determine whether this is a full rebuild ... or "ordinary" build ... ?
I do not know if the exact thing that you are asking can be done - perhaps someone else knows how to do it. I will, however, suggest an alternate approach.
My approach is to remove the build of the Lua library from the pre-link step to a separate Visual Studio NMake project. If you create an NMake project, you will be able to know which type of build (build or rebuild) is occurring.
Note that later versions of Visual Studio simply refer to the project type as "Make". For discussion purposes here, I will refer to the project type as "NMake". I believe this is just a naming difference, and that the underlying build project remains the same between the two versions.
As a simple test, I created two Visual Studio applications: 1) an NMake project that calls a batch file to create a static library, and 2) a console application that consumes the library from step 1.
The NMake Project
In Visual Studio, if you create a new NMake project, you will see a dialog that allows you to provide MS-DOS commands:
As you can see, there are commands for: Build, Clean, Rebuild, and others. I don't have a screen shot of the above dialog with my commands, but here is my NMake project's properties:
My Build command just checks for the existence of the output file (lua.lib). If it does not exist, then it calls the rebuild.bat batch file. My Rebuild command always calls the batch file. My Clean command just deletes the output. I am not really sure what the Output command is used for, but I just filled in the path to the build output (lua.lib).
Now if you do a build, the lua.lib file will only be created if it is not there. If it is already there, nothing is done. If you do a rebuild, then a new lua.lib file is created.
The Console Application
In my console application, I added a reference to the NMake project - this way the NMake project is built prior to the console application. Here is the console application's reference page:
I also added the lua.lib file as an input during the application's link stage:
When the console application is built (during a build), it will build the NMake project if needed, and use the output (lua.lib) during the linker stage. When the console application is rebuilt (during a rebuild), it will also rebuild the NMake project.
Other Thoughts
My screen shots above only show the debug version of the properties. Your projects will have to account for the release version. There probably is a VS macro to handle this, but I am not sure since it has been ages since I've done anything with C/ C++.
In my testing above I use a single build batch file for both the build and rebuild. Obviously, you could do the same or you could use different batch files.
It may be a bit of a hack, but in .csproj file there are sections
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
You can set an variable from BeforeBuild and retrieve it from cmd script. Later on reset this variable in AfterBuild and you should be good to go.
Ok, this is going to be a long one.
First of all - do not take my code 'as is' - it is terrible one with lots of hacks, I had no idea msbuild is so broken by default (it seems at work I have access to waaaay more commands that make life easier). And another thing - it seems vcxproj is broken at some poin - I was not able to integrate the way I wanted with only BeforeRebuild and AfterRebuild targets - I had to redefine hole Rebuild target (it is located in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets)
So, the idea is the following: when a Rebuild is happening we create an anchor. Then, during PreLink stage we execute cmd which is able to use created anchor. If the anchor is in place - we deal with Rebuild, if there is no anchor - it is a simple Build. After Rebuild is done - we delete the anchor.
modifications in vcxproj file:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
....
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
....
<PreLinkEventUseInBuild>true</PreLinkEventUseInBuild>
....
</PropertyGroup>
....
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
.....
<PreLinkEvent>
<Command>D:\PreLink\b.cmd</Command>
</PreLinkEvent>
.....
</ItemDefinitionGroup>
.....
<Target Name="BeforeRebuild">
<Exec Command="echo 2 > D:\PreLink\2.txt" />
</Target>
<Target Name="AfterRebuild">
<Exec Command="del D:\PreLink\2.txt" />
</Target>
<!-- This was copied from MS file -->
<PropertyGroup>
<_ProjectDefaultTargets Condition="'$(MSBuildProjectDefaultTargets)' != ''">$(MSBuildProjectDefaultTargets)</_ProjectDefaultTargets>
<_ProjectDefaultTargets Condition="'$(MSBuildProjectDefaultTargets)' == ''">Build</_ProjectDefaultTargets>
<RebuildDependsOn>
BeforeRebuild;
Clean;
$(_ProjectDefaultTargets);
AfterRebuild;
</RebuildDependsOn>
<RebuildDependsOn Condition=" '$(MSBuildProjectDefaultTargets)' == 'Rebuild' " >
BeforeRebuild;
Clean;
Build;
AfterRebuild;
</RebuildDependsOn>
</PropertyGroup>
<Target
Name="Rebuild"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(RebuildDependsOn)"
Returns="$(TargetPath)"/>
<!-- End of copy -->
</Project>
And the cmd looks like this:
if exist 2.txt (
echo Rebuild818181
) else (
echo Build12312312
)
The output from Output window:
1>Task "Exec" (TaskId:41)
1> Task Parameter:Command=D:\PreLink\b.cmd
1> :VCEnd (TaskId:41)
1> Build12312312 (TaskId:41)
Things to improve:
Use normal variables instead of external file (it seems MsBuild extension pack should do it)
Probably find a way to override only BeforeRebuild and AfterRebuild instead of the hole Rebuild part
It is much easier. Just add the following target to your build file or visual Studio Project
<Target Name="AfterRebuild">
<Message Text="AFTER REBUILD" Importance="High" />
<!--
Do whatever Needs to be done on Rebuild - as the message shows in VS Output
window it is only executed when an explicit rebuild is triggered
-->
</Target>
If you want a two step solution use this as a template:
<PropertyGroup>
<IsRebuild>false</IsRebuild>
</PropertyGroup>
<Target Name="BeforeRebuild">
<Message Text="BEFORE REBUILD" Importance="High" />
<PropertyGroup>
<IsRebuild>true</IsRebuild>
</PropertyGroup>
</Target>
<Target Name="BeforeBuild">
<Message Text="BEFORE BUILD: IsRebuild: $(IsRebuild)" Importance="High" />
</Target>

Merging Visual Studio Code Coverage fails with ImageNotFoundException

I'm trying to export visual studio code coverage files (data.coverage) into xml as described in this blog post from the code analysis team. I've moved the code example in that post into a custom MSBuild task. My custom task references the Microsoft.VisualStudio.Coverage.Analysis.dll located in the PrivateAssemblies folder of Visual Studio.
Right off the bat, trying to load the code coverage file throws an code analysis typed exception ImageNotFoundException, stating that the "Image file fully-qualified-file-path-to-dll could not be found."
// the following line throws an exception
CoverageInfo current =
CoverageInfo.CreateFromFile( "c:\path\testresults\x\y\z\data.coverage");
The path is fully qualified and the DLL it refers to does exist. My testsettings has this file listed as the assembly to instrument and the "Instrument in place" checkbox is set. I can view code coverage within Visual Studio, so I know coverage is working.
I'm running my MSBuild script from the Visual Studio command line. It looks like this:
<Project ToolsVersion="4.0" DefaultTargets="Default;"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="CustomTasks.MergeCoverageTask"
AssemblyFile="CustomTasks.dll"
/>
<Target Name="Default">
<ItemGroup>
<CoverageFiles Include="**\data.coverage" />
</ItemGroup>
<MergeCoverageTask
CoverageFiles="#(CoverageFiles)"
OutputFile="output.xml"
/>
</Target>
</Project>
Can anyone suggest what I need to do to get this working correctly?
5 hours later and this is a tumbleweed. I found some additional detail here, which helped get me further down the path.
In order for this to work, you need to include a few additional files alongside the custom task and supply folder locations for the pdb's and instrumented dll's.
Regarding additional files, you need the following:
The custom build task must reference Microsoft.VisualStudio.Coverage.Analysis.dll
Your bin folder must contain the following additional files:
Microsoft.VisualStudio.Coverage.Symbols.dll
dbghelp.dll
(If you don't have visual studio installed, you must perform regsvr32.exe on msdia100.dll)
Regarding paths to assemblies and symbols, the CreateFromFile method takes a collection of folders to search. What seems really strange is that error complains about not being able to locate missing instrumented assemblies, and it specifies the full path..
Image file c:\project\output\Assembly.dll could not be found.
...but if you specify that path, it doesn't work.
CoverageInfo current =
CoverageInfo.CreateFromFile( "c:\project\testresults\x\In\data.coverage",
new string[] { "c:\project\output" },
new string[] { "c:\project\output" });
However, changing the path to be the folder of the TestResults output works fine:
CoverageInfo current =
CoverageInfo.CreateFromFile( "c:\project\testresults\x\In\data.coverage",
new string[] { "c:\project\testresults\x\Out" },
new string[] { "c:\project\testresults\x\Out" });
I question whether "instrument in place" really means in that folder, or instrument and copy to the MS Test run folder.
Well dear SO folk, if you're reading this, you get a cookie.

run a custom msbuild target from VisualStudio

Suppose I add a custom target to a csproj file. Is there a way to run that target from visual studio? I don't want it make it a prebuild or postbuild step, I just want to be able to run this target (and its dependencies) from visual studio.
There is a simple way (though not all that satisfying) using a custom external tool.
Assuming your project file has the following modification:
<Target Name="CalledFromIde">
<Error Text="Called from the IDE!" />
</Target>
Go to Tools | External Tools and add one like this:
Title: Called from IDE
Command: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
Arguments: $(ProjectDir)$(ProjectFileName) /t:CalledFromIde
Initial directory: $(ProjectDir)
Use Output window: checked
Running this produces output as:
Build FAILED.
"F:\Code\CsProject\CsProject.csproj" (CalledFromIde target) (1) ->
(CalledFromIde target) ->
F:\Code\CsProject\CsProject.csproj(57,5): error : Called from the IDE!
What you are doing is calling out to MSBuild as an external tool and having it run the target directly. You have to supply the full path to MSBuild because the IDE doesn't maintain the same properties that the build environment it creates has available.
You can hook this up to a shortcut by figuring out which command # it is in the set Tools.ExternalCommand#.
If you're looking for a solution with more sophistication, it is a bit more involved. Here it is in a nutshell (for VS2010):
1) Create a VS Addin (File | New | Project | Other Project Types | Extensibility | Visual Studio Add-in). I'm not sure if you have to have the VS SDK installed to get this, it is available in the extension manager.
Select the following options in the wizard:
- Microsoft Visual Studio 2010
- Yes, create a 'Tools' menu item
- Load when the Application starts
- My Add-in will never put up modal UI, and can be used with command line builds.
2) Add references to Microsoft.Build and Microsoft.Build.Framework
3) Find the implementation of Exec in the Connect.cs file
4) Replace it with this code:
public void Exec(
string commandName,
vsCommandExecOption executeOption,
ref object varIn,
ref object varOut,
ref bool handled)
{
handled = false;
if (executeOption != vsCommandExecOption.vsCommandExecOptionDoDefault)
return;
if (commandName != "BuildAddin.Connect.BuildAddin")
return;
var doc = _applicationObject.ActiveDocument;
var projectItem = doc.ProjectItem;
var project = projectItem.ContainingProject;
var evalProject =
Microsoft.Build.Evaluation.ProjectCollection
.GlobalProjectCollection.LoadProject(project.FullName);
var execProject = evalProject.CreateProjectInstance();
bool success = execProject.Build("CalledFromIde", null);
var window = _applicationObject.Windows.Item(Constants.vsWindowKindOutput);
var output = (OutputWindow)window.Object;
OutputWindowPane pane = output.OutputWindowPanes.Add("BuildAddin");
pane.OutputString(success ? "built /t:CalledFromIde" : "build failed");
handled = true;
return;
}
5) A better custom target while debugging, since the previous one errors:
<Target Name="CalledFromIde">
<WriteLinesToFile File="CalledFromIde.txt" Lines="Called from the IDE!" />
</Target>
6) The code above has no error checking for brevity, you'll want to be much cleaner since it will be running in the IDE. The addin will place a menu item on your Tools menu. As written above, it simply looks for the project containing the currently active editor document, which would need some better plumbing for whatever you are cooking up.
This technique gets the build engine instance from within the IDE and has it execute a build on a separate instance of the project.
If you are running the build inside of Visual Studio there will be a build variable of VisualStudioDir during the build.
To execute only is a VS build session do this:
<Target Name="Test" BeforeTargets="Build" Condition="'$(VisualStudioDir)' != ''>
</Target>
To execute only in a build outside of VS do this:
<Target Name="Test" BeforeTargets="Build" Condition="'$(VisualStudioDir)' == ''>
</Target>
You will need to include your custom targets file in one of two ways.
Set the environment variable CustomBeforeMicrosoftCommonTargets
Edit you project file to include your custom targets file by adding an import
<Imports Project="CustomBuildTasks.Targets"><Imports/>
You don't have to code with the Exec, although that is one way to do it. The easier way is to do the following:
Change the DefaultTargets="Build" attribute to a custom Target you create, say "All" like so:
DefaultTargets="All"
Then in your custom "All" target, you can use the DependsOnTargets attribute, like the following:
"<Target Name="All" DependsOnTargets="ZipOutputFiles;Build">
</Target>"
This will then build, and out put zip files in your custom "All" target.
Some time ago I had the same problem and decided to write VS add-in.
Try it:
https://github.com/Serg046/MsBuildTaskExplorer
https://marketplace.visualstudio.com/items?itemName=saaseev.MsBuildTaskExplorer

Automate VS 2010 "Publish" Config File Substitutions

I'm using the config file replacement feature of Visual Studio 2010's "Publish" functionality, as described in this article. I want to automate this using MSBuild/Hudson. Does anybody know how to do this?
I like how it works but if I cannot automate it I'll have to switch to XmlMassUpdate or similar.
Explanation
To transform your config file you'll have to execute the TransformWebConfig target.
This target takes two files Web.config and Web.$(Configuration).config and generates a Web.config. The generated file is the transformed version of the original one for the current configuration.
This file is generated in folder : obj\$(Configuration)\TransformWebConfig
Usage
You don't really explain what you want to achieve, so here a basic usage, a job that generates a transformed config file in a given folder.
Add the following piece in the end of your project file *.csproj after the import of Microsoft.WebApplication.targets
<PropertyGroup>
<!-- Directory where your web.config will be copied -->
<TransformedWebConfigDestination>$(MSBuildProjectDirectory)</TransformedWebConfigDestination>
</PropertyGroup>
<!--
This target transforms the web.config based on current configuration and
put the transformed files in $(TransformedWebConfigDestination) folder
-->
<Target Name="ConfigSubstitution">
<CallTarget Targets="TransformWebConfig"/>
<ItemGroup>
<TransformedWebConfig Include="obj\$(Configuration)\TransformWebConfig\Web.config"/>
</ItemGroup>
<!-- Copy the transformed web.config to the configured destination -->
<Copy SourceFiles="#(TransformedWebConfig)"
DestinationFolder="$(TransformedWebConfigDestination)"/>
</Target>
In Hudson you could add a Build step in your build, or create a dedicated job configured as follow:
MsBuild Build File : Your csproj file.
Command Line Arguments : /t:ConfigSubstitution /p:Platform=AnyCpu;Configuration=Test;TransformedWebConfigDestination=DestinationFolder
Edit your web project.csproj
under
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
Add -
<UseMsDeployExe>True</UseMsDeployExe>
Look at the Build output (make sure VS Tools - Options - Project & Solutions -Build & Run - MSBuild Output Verbosity - Detailed)
You should be able to see the msdeploy commands VS uses to produce the package. It's my understanding that VS actually uses Web Platform Pipeline API's and .target files to actually produce the deploy packages when building using MSBuild, and this command changes to use MsDeploy instead.
This stuff is so in need of documentation, its very frustrating.
I am using this in Hudson to target Release:
/Property:Configuration=Release
The exact settings are:
Build
MSBuild Version: msbuild-4 (configured to point to v4 msbuild)
MsBuild Build File: project_name.sln
Command Line Arguments: /Property:Configuration=Release
You can test this in your project directory by running something similar (as your .NET framework version may differ) to this:
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\msbuild project.sln /Property:Configuration=Release

Resources