I generated Fxcop analysis report using ant script. But I am unable to host it on Hudson Dashboard.
Using Nant script, I am able to generate an .xml output. Here is the ant:
<target name="Fxcop">
<echo message="Running Fxcop..." />
<exec command="${fxcop.basedir}\FxCopCmd.exe">
<arg value="/f:Path of my source file/>
<arg value="/out:some path/>
</exec>
</target>
In hudson Configuration, To display Vioaltion Reports, i configured the path of output(only pattern) file of the ant in xml file pattern of fxcop.
But Hudson is unable to find it.
I done the configurations and setting correctly.
Can anyone walk me through where I am going wrong.
Thanks in Advance
Most likely XML is created in different subfolder which relative path is originated from current directory. E.g. if your current working directory is %WORKSPACE%\trunk and relative path for report is /out:result\fxcop-result.xml then it will be created in %WORKSPACE%\trunk\result\fxcop-result.xml.
To fix this I suggest to check current directory from which you are executing FxCop analysis (also try searching this xml on build machine).
Easiest way to implement FxCop analysis in Hudson using Windows batch command will be:
Add "Execute Windows batch command" (this command will be executed from base workspace folder, e.g. C:\hudson\workspace\FxCopJob)
Specify command that will execute analysis, e.g.: ""{FxCopDirectory}\fxcopcmd.exe" /file:"%WORKSPACE%\{path to your file}" /directory="{Assemblies_path}" /rulesetdirectory:"{RuleSetDir}" /out:fxcop-result.xml"
Set fxcop-result.xml in fxcop section of Report Violation (e.g. report will be created in C:\hudson\workspace\FxCopJob\fxcop-result.xml)
Run updated Hudson job and verify that FxCop violations are shown
WBR,
Andrey
Related
I have a console application that has <TargetFramework>net6.0</TargetFramework>. I am trying to use the exe of this console application in the wix project for creating the setup as shown below:
<Component Id="_COMP_ConsoleApp_exe" Guid="{34407E06-98A0-4CF3-8021-F9533CFE537D}">
<File Id="_FILE_ConsoleApp_exe" Name="ConsoleApp.exe" KeyPath="yes" Source="$(var.ProjectSourceDir)\ConsoleApp.exe" />
</Component>
But during the build it gives the error "The system cannot find the file ..\Release\ConsoleApp.exe". The ConsoleApp.exe is getting created in the Release folder.
That error indicates the file is not in the location you specified. To debug, try putting the full path to the file on your computer in the File/#Source attribute. Once you know you have the right path, then try using BindPaths or, if you must, preprocessor variables to make the location more generic.
I expect you'll find the folder ..\Release\ is not the one you thought it was.
Note: the Name and KeyPath attributes are unnecessary as they will default to those values.
I'm trying to create a build process using cruise control 1.8.5.0 with TFS 2010 running on a windows server 2008 R2 machine. The problem I'm running into is when MS Build is trying to write to files that ere just copied into the projects area it gets access denied. When I look at the files they are set to read only, the account that ccnet is running as is an admin on the box and everything is reading and writing locally. We have a similar environment setup on Windows Server 2003 and everything works just fine. We've verified that the account that is running the process is correct, I've set the owner of the projects folder to the same account that is running the process, we've disabled UAC. At this point I'm at a loss. Any additional information needed let me know.
Thanks
Robert
//When I look at the files they are set to read only, //
You can run the attrib to remove the read-only flag on the files.
quick example:
<Exec Command=“attrib -R $(SolutionRoot)\MyCoolFile.txt“ />
There is also a custom task:
<UsingTask AssemblyFile="$(MSBuildCommunityTasksLib)" TaskName="MSBuild.Community.Tasks.Attrib" />
I've not used it, but that would be enough to hunt it down.
I'd guess it would look like this:
<ItemGroup>
<Files Include="$(SolutionRoot)\MySubFolder\**\*.*/>
</ItemGroup>
<Attrib Files="%(Files.Identity)" ReadOnly="true"/>
I'm executing a large sequence of many fixtures with tests within them. Within each test is code to log any errors to a file based on NUnit attributes. Once the execution is complete, the file contains all of the errors in a nice format to send off to the consultants.
First of all, I need a hook to delete the previous copy of the file so that the file can be freshly generated. If this were a series of tests in a single fixture, it would be a chip-shot - put it in the fixture setup. But I need these dozens of test fixtures to share a common file, so putting it in the fixture setup doesn't work.
Second of all, this all just feels like reinventing the wheel...if there's some awesome NUnit standard for shunting results to an alternate output, I'd love to hear about that.
TIA.
The easiest way to do this is to merge the many NUnit files your suite generates into a single one. This answer links to a library created to do the merge as an MSBuild task.
The first step is to compile that library (no issues for me when I tried) and put the built assembly in a directory with the following MSBuild project (or something similar):
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
ToolsVersion="4.0"
DefaultTargets="UnitTest">
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\15below.NUnitMerger.dll"
TaskName="FifteenBelow.NUnitMerger.MSBuild.NUnitMergeTask" />
<Target Name="UnitTest">
<ItemGroup>
<ResultsFiles Include="$(MSBuildProjectDirectory)\nunit-result*.xml" />
</ItemGroup>
<NUnitMergeTask FilesToBeMerged="#(ResultsFiles)"
OutputPath="$(MSBuildProjectDirectory)\TestResult.xml" />
</Target>
</Project>
Here, I'm assuming your files are set up in the same directory, i.e.:
Once your NUnit results are in the directory, run MSBuild from this directory to get your output:
msbuild merge.msbuildproj
The resulting file (here it's TestResult.xml) has the same format as the normal Xml output from NUnit, but has all the test-suite type=Assembly nodes from the input files.
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.
I have the following target in my nant script:
<target name="update" verbose="true">
<copy todir="${dirs.deploy}">
<fileset basedir="${dirs.drop}\_PublishedWebSites\RomanceReminder.Web">
<include name="**/*.*" />
</fileset>
</copy>
</target>
when I run this script manually the following output is visible in the log:
[nant]
C:\Projects\RomanceReminder\BuildScripts.Custom_test_deploy.build
Buildfile:
file:///C:/Projects/RomanceReminder/BuildScripts.Custom/_test_deploy.build
Target framework: Microsoft .NET
Framework 3.5
Target(s) specified: go
error_check:
stop_w3svc:
cleanup:
[echo] Deleting C:\Webs\Nightly.
update:
[copy] Copying 93 files to
'C:\Webs\Nightly'.
start_w3svc:
go:
BUILD SUCCEEDED
Total time: 2.6 seconds.
As you can see it move 93 files into the web\nightly folder.
When this script is run via TeamCity the copy doesn't happen for some reason. Team city is running under an admin account so it should have all the permissions it needs. The log file for TC show the exact text above except the update task shows nothing.
Anyone have ideas on how I can even troubleshoot this?
UPDATE: I flipped the bit on the copy task to give verbose logging. and now I see the following in my TeamCity log:
[copy] Copying 0 files to 'C:\Webs\Nightly'.
I still am flummoxed by I can run it from the command line and everything works, but TC doesn't copy files... 8(
User Error User Error User Error
Of course, I was not trusting the tool assuming it was doing something wrong. The drop directory is only populated in the package step. This particular script executes before that. Team City destroys the build directory every time it runs including the drop directory. So nant was correct, there were no files to copy. I modified my script to use the build output and all is good with the world.