I have to run two targets in parallel to profile iisexpress.exe using OpenCover.
The link below relates to the information about the issue I am having.
https://github.com/sawilde/opencover/issues/92#issuecomment-5143204
This suggested to me to use Msbuild.ExtensionPack from CodePlex.
I have downloaded the source code of MSBuild Extensions.
I compiled it. I copied the MSBuild.ExtensionPack.tasks tasks file in to folder BuildBinaries.
I added the below lines in my projects files.
I was trying to run the ExecMultipleTasks target. But getting the below error.
error MSB4036: The "MSBuild.ExtensionPack.Framework.Parallel" task was not found. Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with in the project file, or in the *.tasks files located in the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" directory.
Could you please let me know how to fix this issue?
Thanks,
Venkat.
which version of visual studio your application is using ?, if its 32 bit of VS then install 32 bit Extension Pack (MSBuild.Extension.Pack.4.0.12.0.zip\4.0.12.0\x86) else go for 64 bit.
If you open up the file C:\Program Files (x86)\MSBuild\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks ill think you find that the path to the dll for the task MSBuild.ExtensionPack.Framework.Parallel is not correct.
<UsingTask AssemblyFile="$(ExtensionTasksPath)MSBuild.ExtensionPack.dll" TaskName="MSBuild.ExtensionPack.Framework.Parallel"/>
I imagine the variable $(ExtensionTasksPath) does not locate your build path for your version. Either copy the files into that path or change/hardcode the new path.
Related
I try to integrate StyleCop in a Visual Studio solution. Installing StyleCop on each machine of each developer is something I would prefer to avoid. The suggestion I've seen several times (example) is to include the binaries of StyleCop within the project, storing them in version control.
I did that. It works on my machine, but fails on a different machine where StyleCop is not installed. After uninstalling StyleCop on my machine, it doesn't work there either.
The error message is the following:
Severity Code Description Project File Line
Error The "StyleCopTask" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild..\StyleCop 4.7\StyleCop.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\StyleCop 4.7\StyleCop.dll' 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. Demo
This is what I included in every .csproj file:
<Import Project="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.targets" />
The directory C:\demo\externs\Microsoft.StyleCop contains:
The copy of all the files from C:\Program Files (x86)\StyleCop 4.7,
The copy of C:\Program Files (x86)\MSBuild\StyleCop\v4.7\StyleCop.Targets.
What's wrong?
It appears that StyleCop.Targets contains an absolute path:
<UsingTask
AssemblyFile="$(MSBuildExtensionsPath)\..\StyleCop 4.7\StyleCop.dll"
TaskName="StyleCopTask"/>
In order to be able to use StyleCop on machines where the application is not installed, change this path to something similar to:
<UsingTask
AssemblyFile="$(SolutionDir)\externs\Microsoft.StyleCop\StyleCop.dll"
TaskName="StyleCopTask"/>
I am trying to read a .wav file and hence need to include the libsndfile binary in my project. I am using NetBeans 7.0 and the Tools->Library->Add new library option doesnt work since the Add library button is disabled.
I tried adding the path of the header file to the Project->Build properties and the code compiled. But when I try to add the .dll in a similar way via Project->Linker properties NetBeans is unable to find the .dll. If i navigate to the folder from MyComputer->..i can see the .dll/ However NetBeans doesn't display it.
I am using a Win 7 64 bit machine & I have setup the appropriate libsndfile binary. Been at it for a day now. Would appreciate any help.
Thanks,
Neeraj
DLL doesnotrequires setting of class path. So you can load a DLL from local file system. Copy the DLL and go to the file explorer tab strip and paste the file.
First you have to check that your compiler version (32 or 64 bit) matches libsndfile version. I suppose you did it correctly.
I also suppose you correctly added the sndfile.h to the include path.
You will need two library files actually. I think you forgot the one to compile properly.
Compiling and Linking (.lib file)
Note that Netbeans 7.0 doesn't accept .lib files and you need to link the .lib file for your project to compile. So, in C:\Program Files\Mega-Nerd\libsndfile\lib you need to copy libsndfile-1.lib and rename the .lib extension to .a.
Then, in Poject Properties > Build > Linker > Additional Libraries Directories add the path to the \lib directory. For me it's Program Files/Mega-Nerd/libsndfile/lib.
A few lines below, you'll have Poject Properties > Build > Linker > Libraries. Specify the location of the library file named libsndfile-1.a, for me it's C:\Program Files\Mega-Nerd\libsndfile\lib\libsndfile-1.a.
Now it should at least compile.
Executing (.dll)
Now, it likely will not execute even if it compiled. That's because the .dll file is needed to execute the final .exe. Simply copy the libsndfile-1.dll file (for me it's in C:\Program Files\Mega-Nerd\libsndfile\bin) to your project, next to the .exe file. For me, it's in C:\proj\dist\Debug\Cygwin-Windows\proj.exe.
Edit: I checked with the today's 8.2 version of NetBeans, and the procedure is exactly the same.
I have had my first successful build using CC.Net + MSBuild on legacy project. Only took 8 hours.
My newb question is: Where is the output?
My ArtifactDirectory is empty. Where did everything go?
Did you specify the ThoughtWorks.CruiseControl.MSBuild.dll logger in the msbuild-task? Did you have the xmllogger publisher?
EDIT:
What are you looking for : the results/logs that goes into the dashboard and mail or the website/dll/program you built?
Could you post your project configuration?
EDIT2:
The website/dll you built are located in the outDir you specified in your msbuild task. If you didn't override either the OutDir or the OutputPath property (in your msbuild task or msbuild build script) your website should be located in the WebProject\bin\Release (or Debug)_PublishedWebsites and your dlls should be located in every Project_dir\bin\Release (or Debug).
If you want a common output you need to specify it by overriding OutputPath or BaseOutputPath (see here http://msdn.microsoft.com/en-us/library/bb629394.aspx ).
If your source projects don't compile to custom folders, the code will be located wherever the source was pulled down to on the build box. As Benjamin stated, this will be the workingDirectory specified in the msbuild task.
If you didn't specify a working directory, I believe CruiseControl.net puts code in:
C:\Program Files\CruiseControl.NET\server\[Project Name]\WorkingDirectory
I know that the latest book out on MSBuild says this is not possible, but I am sure I have seen a property that points to the current file.
Does anyone know a way to find the current file? (ie When the main MSBuild file imports a secondary file. What is the path to the secondary file from inside that file.)
I am trying to register my file in HKEY_LOCALMACHINE\Software\Microsoft\VisualStudio\8.0\MSBuild\SafeImports, but the path to the file is not constant on each of my coworkers computers and it is imported from several different projects so doing a hard coded relative path is not a good idea either.
If there is a way to get the current working directory that will work too (the working directory switches with each import and I think I could save it off)
There is not a reliable means to identify the "current file". When MSBuild processes a file it can import several other files, the end result is a single in memory complete representation of the file. When the targets are executing they do not know which file they were declared in.
This is why reusable build scripts must be "parameterized" to accept the location to known relative locations. For example if you have a dependency on the location where your folder for 3rd party references are located, the build script which is driving the process must declare that property for you.
MSBuild 4.0 Only
If you are using MSBuild 4.0, i.e. Visual Studio 2010/.NET 4.0, (which can target .NET 2.0/3.0/3.5) as well. Then you now have these properties which can be used for this specific purpose:
MSBuildThisFile
MSBuildThisFileDirectory
MSBuildThisFileDirectoryNoRoot
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
In 4.0+ you can use properties like $(MSBuildThisFile) to do exactly this. See here
Here's my situation: I'm trying to understand how msbuild works by looking at the build files located in the .NET framework install path:
C:\Windows\Microsoft.NET\Framework\v3.5>dir /s/b microsoft*
Microsoft.Build.Tasks.v3.5.xml
Microsoft.Build.xsd
Microsoft.Common.targets
Microsoft.Common.Tasks
Microsoft.CSharp.targets
Microsoft.Data.Entity.targets
Microsoft.VisualBasic.targets
Microsoft.WinFx.targets
MSBuild\Microsoft.Build.Commontypes.xsd
MSBuild\Microsoft.Build.Core.xsd
I'm assuming that msbuild starts with Microsoft.Common.Targets, and then at some point in the future msbuild 'looks' at my vb project file extension (.vbproj) and loads 'Microsoft.VisualBasic.targets'.
two questions:
1) Is my interpetation correct?
2) can you explain to me, where is the code that determines that this is a .vbproj file, and loads 'Microsoft.VisualBasic.targets' accordingly? Is the code locked away in an assembly somewhere, or is it visible in the build files listed above?
It "starts" with your .vbproj file. Take a look at that file, it will <Import> the Microsoft.VisualBasic.targets, which in turn will <Import> Microsoft.Common.targets.
In 4.0, which is currently available in Beta, there is a /preprocess switch which will make this all clear.