This is my Ncover task portion in my MSBuild script
<UsingTask TaskName="NCoverExplorer.MSBuildTasks.NCover" AssemblyFile="$(Libraries)\NCoverExplorer.MSBuildTasks.dll"/>
<Target Name="NcoverCoverage">
<NCover ToolPath="C:\Program Files\TestDriven.NET 3\NCover\1.5.8"
CommandLineExe="C:\Program Files\TestDriven.NET 3\NUnit\2.5\nunit-console.exe"
CommandLineArgs="MyTestProject.dll"
WorkingDirectory="MyWorkingDirectory"
LogFile="coverage.log"
/>
</Target>
This NCover task executes fine and creates an output xml file (Coverage.xml). This output xml file contains a reference to a xsl file (Coverage.xsl) which is missing in my machine.
<?xml-stylesheet href="coverage.xsl" type="text/xsl"?>
I cant find this file anywhere. Due to this, hen I try to open the Coverage.xml file, it throws an error
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.
Access is denied. Error processing resource 'file:coverage.xsl'.
Where can i find my coverage.xsl file?
Thanks.
The coverage.xsl file is available in the install directory (C:\Program Files\NCover) once you install the NCover Community Edition located here:
http://www.ncover.com/download/current
NCover Support
Related
I have UWP app build in VS 2017 and many project in my solution have build warning like below. How to get rid of them?
Warning "C:\Program Files (x86)\MSBuild\15.0.Net\CoreRuntime\Microsoft.Net.CoreRuntime.targets" cannot be imported again. It was already imported at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\Microsoft.Net.CoreRuntime.ImportAfter.targets (17,3)". This is most likely a build authoring error. This subsequent import will be ignored. [D:\Projects\HA4IoT\Controllers\HA4IoT.Controller\HA4IoT.Service.csproj] HA4IoT.Tests
Warning "C:\Program Files (x86)\MSBuild\15.0.Net\CoreRuntime\Microsoft.Net.CoreRuntime.Settings.targets" cannot be imported again. It was already imported at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportBefore\Microsoft.Net.CoreRuntime.ImportBefore.targets (17,3)". This is most likely a build authoring error. This subsequent import will be ignored. [D:\Projects\HA4IoT\DNF\HA4IoT.Extensions.Tests\HA4IoT.Extensions.Tests.csproj] HA4IoT.Controller.Dnf
Warning "C:\Users\dnf.nuget\packages\microsoft.net.native.compiler\1.6.3\tools\Microsoft.NetNative.targets" cannot be imported again. It was already imported at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Microsoft.Common.targets\ImportAfter\Microsoft.NetNative.ImportAfter.targets (16,3)". This is most likely a build authoring error. This subsequent import will be ignored. [D:\Projects\HA4IoT\Controllers\Examples\HA4IoT.Controller.Main\HA4IoT.Controller.Main.csproj] HA4IoT.Controller.Main
How to get rid of them?
I found the work-around of this question on MSDN:
Using condition to check the existence of a unique property defined in the considering project file.
<PropertyGroup>
<TasksTargetsImported>true</TasksTargetsImpor‌​ted>
</PropertyGroup>
<Import Project="Tasks.targets" Condition=" '$(TasksTargetsImported)' == '' "/>
Hope this can helps.
I removed all nuget target and prop files next to the .csproj files. This worked for me. All warnings are now gone.
Unload project or edit project solution file then check entire project file and make sure the same line is not repeated twice. In my case after I followed Web.config transformation instructions I added an extra line like the one below by mistake. You just want to make sure you have no dupes.
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets" />
I had the error "\PrefixFidelity\obj\PrefixFidelity.csproj.nuget.g.props(16,5): warning MSB4011: "..."This is most likely a build authoring error. This subsequent import will be ignored."
trace it to a second props file in the obj folder:
PrefixFidelity.csproj.nuget.g.(2)props
once that file was deleted the error was gone
I got this issue using the CLI tools after updating VS2017,
The fix was to simply delete the bin/obj folders, not modifying the targets file
I ran into this problem after importing an azure publish profile. My .csproj was updated from:
<Project Sdk="Microsoft.NET.Sdk">
to:
<Project Sdk="Microsoft.NET.Sdk;Microsoft.NET.Sdk.Publish">
Reverting that change removes the warning and the publish process still works ok.
I'm using visual studio 2019, this is an Azure Functions project, targeting .net core 3.1.
I am trying to obfuscate bunch of files in a directory and every build there are more and more files being generated. I would like to know if there is a way I can dynamically create the Dotfuscator configuration xml file using a MSBUILD task that will generate the xml file every time there is a new file added to the directory?
This might be a good time to use the Directory input. Rather than representing a single assembly (.exe or .dll), this type of Dotfuscator input captures all the assemblies in a directory. When the contents of the directory change, Dotfuscator's build will automatically pick up any new assemblies.
To make a Dotfuscator config file with a Directory input, open the GUI and add an input as you normally would (directions for Community Edition's GUI and for Professional Edition's standalone GUI), but instead of selecting a file from the Browse... dialog, just navigate to the directory and click "Open" while the "File name" is still listed as "Folder Select". Then, save your configuration.
From now on, whenever you run Dotfuscator (whether from the standalone GUI, the command line, the Visual Studio integration, or the MSBuild task), all assemblies in the directory will be processed as input.
Note: If you look at the config file itself, you might be surprised that it will still list individual assemblies:
<input>
<loadpaths />
<asmlist>
<package refid="19e1b0c5-7221-476f-af4b-bafef68edc95">
<file dir="C:\code\BasicTestApp\BasicTestApp\bin" name="Debug" />
<asmlist>
<inputassembly refid="a6da5d8d-c181-4103-840d-d8cc7c85937a">
<option>honoroas</option>
<option>stripoa</option>
<option>transformxaml</option>
<file dir="" name="BasicTestApp.exe" />
</inputassembly>
<inputassembly refid="df84dad0-fbe8-49ab-b8c8-9fb59e706785">
<option>honoroas</option>
<option>stripoa</option>
<option>library</option>
<option>transformxaml</option>
<file dir="" name="ClassLibrary.dll" />
</inputassembly>
</asmlist>
</package>
</asmlist>
</input>
Despite this layout, Dotfuscator will process all assemblies in the C:\code\BasicTestApp\BasicTestApp\bin\Debug directory when it runs a build based off this config file, not just those two listed.
The assembly elements in the config are just there so that you can still make rules against individual assemblies in the GUI (e.g., to make one assembly be in Library Mode).
The list represents the state of the directory when the GUI last modified the config.
Disclaimer: I work for the Dotfuscator team, and am answering this question as part of my job.
Additional note due to clarification in the comments: the directory package has a feature where you can exclude certain assemblies from obfuscation. These assemblies will be treated as a Package Artifact and just copied from input-to-output without modification. Any obfuscated assemblies that refer to these excluded assemblies will still be processed correctly.
To do this in the GUI, right-click on the assembly within the package, and select "Exclude assembly from package". Or, if you'd prefer to edit the config file, add the following <option> tag as a child of each relevant <inputassembly> tag:
<option>artifact</option>
The latest Dotfuscator version 4.41.1 has the latest flag
true
This will generate the Dotfuscator config file if the file is missing. Also you can add this to the csproj as documented in the latest getting started guide https://www.preemptive.com/dotfuscator/pro/userguide/en/getting_started_protect.html
I have tried searching the web for a solution to this problem but it seems very unclear. It sounds like people are seeing this but the solutions don't seem to work for me.
I have downloaded and installed YUICompressor.NET.MSBuild 2.3.0.0 from NuGet into my project.
I have created an MSBuild target file that closely resembles the example file included and exists as part of my .csproj file so I can run it in the AfterBuild step.
I am getting the following error everytime I try to build my VS project:
The "JavaScriptCompressorTask" task could not be loaded from the assembly SolutionDir\packages\YUICompressor.NET.MSBuild.2.3.0.0\lib\NET20\Yahoo.Yui.Compressor.Build.MsBuild.dll.
Could not load file or assembly 'Yahoo.Yui.Compressor, Version=2.3.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
My folder structure is as follows:
\Solution
\packages
YUICompressor.NET.MSBuild.2.3.0.0\lib\NET20\
\build
ProjectFile.csproj
In the csproj I have:
<UsingTask TaskName="CssCompressorTask" AssemblyFile="packages\YUICompressor.NET.MSBuild.2.3.0.0\lib\NET20\Yahoo.Yui.Compressor.Build.MsBuild.dll" />
<UsingTask TaskName="JavaScriptCompressorTask" AssemblyFile="packages\YUICompressor.NET.MSBuild.2.3.0.0\lib\NET20\Yahoo.Yui.Compressor.Build.MsBuild.dll" />
<Target Name="AfterBuild">
<ItemGroup>
<JavaScriptFiles Include="someFile.js" />
</ItemGroup>
<JavaScriptCompressorTask SourceFiles="#(JavaScriptFiles)" OutputFile="build\combined.js" DeleteSourceFiles="false" CompressionType="None" ObfuscateJavaScript="false" PreserveAllSemicolons="true" />
<JavaScriptCompressorTask SourceFiles="#(JavaScriptFiles)" OutputFile="build\combined.min.js" DeleteSourceFiles="false" CompressionType="Standard" />
</Target>
Am I missing something? Can anyone help me? Thank you.
Did you try to download version 2.3.0.0 directly from codeplex? Then make sure that the Yahoo.Yui.Compressor.Build.MsBuild.dll and Yahoo.Yui.Compressor.dll reside in the same directory. Like this I was able to make it work.
It's been a while since i've played around with the AfterBuild .. but how this works is that the the msbuild program is ran from some directory .. and therefore looks for those assembly files RELATIVE to where the msbuild is being executed from.
I'm not sure if this means the msbuild is being run from C:\program files(x86)\Microsoft Visual Studio\<whatever...>
TAKE NOTE: it's the folder/path (aka execution path) where visual studio is running the msbuild command from ... NOT where msbuild exists.
So therefore, it can't find the assemblies.
Try putting in the full path to the assemblies (just to see if that works).
eg. C:\Projects\Solution\packages\YUICompressor.NET.MSBuild.2.3.0.0\lib\NET20\Yahoo.Yui.Compressor.Build.MsBuild.dll
If it's running it from the \solution\bin directory, then you're in luck! cause then you can do ..\packages\YUICompressor.NET.MSBuild.2.3.0.0\lib\NET20\Yahoo.Yui.Compressor.Build.MsBuild.dll' (the..means: from thisbindirectory, go up one level tosolutionthen down intopackagesand then down intoYUIComp`... etc.
So the answer to your question is this: Find the location Visual Studio is running the msbuild command from, during an AfterBuild. Maybe put in some code in there to say 'write to file => current path i'm in :P'
I'm trying to set up CCNET and I've run into a problem.
My builds are failing and I'm getting this error
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.
In my configuration file ccnet.config my msbuild block is as follows
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
<workingDirectory>C:\example\directory</workingDirectory>
<projectFile>ExampleSolution.sln</projectFile>
<buildArgs>/noconsolelogger /v:quiet
/p:Configuration=Debug
/p:ReferencePath="C:\Program Files (x86)\NUnit 2.5.10\bin\net-2.0\"
</buildArgs>
<targets>ReBuild</targets>
<timeout>600</timeout>
</msbuild>
In this case, C:\example\directory has multiple solution files. Even though I specified the project file I'm still getting that error.
You should specify what to build in the sln group.
msbuild SlnFolders.sln /t:NotInSolutionfolder:Rebuild;NewFolder\InSolutionFolder:Clean
So in CC.NET, add the /t parameter in the <buildArgs> tag.
Reference : http://msdn.microsoft.com/en-us/library/ms164311.aspx
TFS 2008, VS 2008.
I have a tfsbuild.proj and tfsbuild.msp file in $/MyStuff/TeamBuildTypes/Dev folder.
I have a targets file at $/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml.
test.xml contains an XML fragment that overrides the BeforeGet task.
I tried to get the file into my tfsbuild.proj file like this:
<Import Project="$/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml" />
The build fails because it tries to get the file from a relative path that is way off.
I have shifted gears a little and am now trying an Exec task to get the file from TFS into the local filesystem.
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TF)" get "$/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml" /version:W$(WorkSpaceName) /overwrite /force /noprompt /recursive" IgnoreExitCode="true" />
I have no idea where the file is going. I don't get an error. I have access to the $(SolutionRoot) variable but the TeamBuildTypes folder is above that one in the filesystem. How can I get to this file and use it as an overrride to my task for the current build?
Help?
Thanks!
That's not a "remote" path. It's a path into TFS source control. It can only be understood by TFS.
MSBUILD is not part of TFS - it's part of the .NET SDK. It can only understand the kind of paths all programs can understand.
You'll have to fetch this file from source control onto the build machine, and reference it with a path to where you fetched it.