Am I missing something, or does xbuild really not implement the <Move> task? I'm trying to build a cross-platform C# project using MSBuild files for everything so there will be less difference between Windows and Linux in our project, and my MSBuild file looks a little like this:
<Copy SourceFiles="$(SrcDir)/$(FirstFile);$(SrcDir)/$(SecondFile)" DestinationFolder="$(DestDir)" />
<Move SourceFiles="$(DestDir)/$(SecondFile)" DestinationFile="$(DestDir)/$(NewFileNameForSecondFile)" />
But when I run xbuild, it complains:
Error initializing task Move: Not registered task Move.
What am I missing? I know that xbuild doesn't implement some of MSBuild's more recent and/or more advanced features — I've had to work around a few of those omissions — but the <Move> task seems like a really, really basic one. Is it really not implemented in xbuild, or am I missing something obvious?
I think Move falls under TaskExtensions within MSBuild. You would need to convert it to a Copy and Delete or multiple platform specific Tasks:
List of TaskNames in xbuild (mono 4.2.x):
cd mono/mcs/tools/xbuild
grep -RI "TaskName=" * | cut -d "=" -f 2 | cut -d " " -f 1 | sort | uniq
"Microsoft.Build.Tasks.AL"
"Microsoft.Build.Tasks.AssignCulture"
"Microsoft.Build.Tasks.AssignLinkMetadata"
"Microsoft.Build.Tasks.AssignProjectConfiguration"
"Microsoft.Build.Tasks.AssignTargetPath"
"Microsoft.Build.Tasks.CallTarget"
"Microsoft.Build.Tasks.CombinePath"
"Microsoft.Build.Tasks.Copy"
"Microsoft.Build.Tasks.CreateCSharpManifestResourceName"
"Microsoft.Build.Tasks.CreateItem"
"Microsoft.Build.Tasks.CreateProperty"
"Microsoft.Build.Tasks.CreateVisualBasicManifestResourceName"
"Microsoft.Build.Tasks.Csc"
"Microsoft.Build.Tasks.Delete"
"Microsoft.Build.Tasks.Error"
"Microsoft.Build.Tasks.Exec"
"Microsoft.Build.Tasks.FindAppConfigFile"
"Microsoft.Build.Tasks.FindUnderPath"
"Microsoft.Build.Tasks.GenerateResource"
"Microsoft.Build.Tasks.GetAssemblyIdentity"
"Microsoft.Build.Tasks.GetFrameworkPath"
"Microsoft.Build.Tasks.GetFrameworkSdkPath"
"Microsoft.Build.Tasks.GetReferenceAssemblyPaths"
"Microsoft.Build.Tasks.LC"
"Microsoft.Build.Tasks.MSBuild"
"Microsoft.Build.Tasks.MakeDir"
"Microsoft.Build.Tasks.Message"
"Microsoft.Build.Tasks.ReadLinesFromFile"
"Microsoft.Build.Tasks.RemoveDir"
"Microsoft.Build.Tasks.RemoveDuplicates"
"Microsoft.Build.Tasks.ResolveAssemblyReference"
"Microsoft.Build.Tasks.SignFile"
"Microsoft.Build.Tasks.Touch"
"Microsoft.Build.Tasks.Vbc"
"Microsoft.Build.Tasks.Warning"
"Microsoft.Build.Tasks.WriteCodeFragment"
"Microsoft.Build.Tasks.WriteLinesToFile"
Related
The real problem
I want to apply project level source code formatting to all modified files
Current approach
Use add_custom_target in my top-level CMakeLists.txt file to call a script that applies formatting rules to all files the SCM tool reports as modified:
add_custom_target(Name ALL ${PROJECT_SOURCE_DIR}/../cmake/format_files.bash
)
This rule is before any add_subdirectory calls, because reformatting should take place before all compilation.
Per the documentation:
ALL
Indicate that this target should be added to the default build target so that it will be run every time (the command cannot be called ALL).
When CMake itself runs (like any modification to the CMakeLists.txt files), all is good.
The Symptom
Suppose I perform some spacing-related modification to file Foo.hh (my rules replace tabs with spaces, for example). My build is likely to include something like this:
Scanning dependencies of target Foo
make[2]: Warning: File `projects/foo/src/Foo.hh' has modification time 8.7 s in the future
...
make[2]: warning: Clock skew detected. Your build may be incomplete.
I'm pretty sure it's the source formatting script that somehow runs after dependency scanning (or something like that), modifies Foo.hh, and creates the illusion of clock skew.
What I think the question is
What is the right way to force my build process to assert project standards for source code style prior to building, without potentially creating dependency problems?
Is there a better way to introduce formatting to the build process?
Red Herrings
At first, I thought I was dealing with a true clock skew problem; my development environment is on a VMware VM, and we have had some issues with time in the past, but now I'm 99% sure that all the VMs are using host time. Furthermore, a simple test like this (in the same filesystem as my builds) proves there is no intrinsic clock skew:
$ date ; touch foo ; ls --time-style=+%H:%M:%S -l foo ; date
Thu Jan 17 12:48:59 MST 2019
-rw-rw-r--. 1 1001 1001 0 12:48:59 foo
Thu Jan 17 12:48:59 MST 2019
A key facet of the source code formatting process is that there is no deterministic way to know which files might be modified in the script and which will not. Files that comply with project standards are not touched.
For completeness, here is the script:
#!/bin/bash
# This script is intended to format any modified files to project standards
# Change to the project root
cd $(dirname $0)/..
outfile=format.log
file_list=$( git status --short --untracked-files=all src \
| awk '/^( M|\?\?) .*\.(cpp|hh)/ {print $2}' )
# If we haven't changed any files, exit gracefully
[[ -z $file_list ]] && exit 0
# Format the current working set
echo >> ${outfile}
date '+%Y-%m-%dT%H:%M:%S.%N: ' >> ${outfile}
astyle --project $file_list >>${outfile} 2>&1
This script appends to an output file (I'll probably remove that at some point) that looks like this:
2019-01-17T18:54:20.641765133:
Unchanged src/Foo.cpp
Formatted src/Foo.hh
Unchanged src/Bar.cpp
Based on the discussion at https://discourse.cmake.org/t/cmake-pre-build-command/1083, the answer is "don't do that". Formatting can be a target and building can be a target, but having a build step that modifies the dependencies of another build step (after the dependency tree has been evaluated) is bad.
Instead of formatting my code as part of the build, I added it as a CI check on the build server: if formatting would change the code, the build fails. I also created a pre-commit hook to tell me if my code needs formatting. I don't like hooks that change the code checked in; changed code should always be compiled before commit.
A user checked new files on the wrong branch. I would like to move them in the most efficient way there is a lot of them. My first thought is to remove the element from the branch and have the user recheck in the files on the proper branch. But I was hoping there was a way i could change the pointers?
/VOB/DIRECTORY/file##/main/1.00/1 to /VOB/DIRECTORY/file##/main/2.00/1
Whenever there are a lot of files to checkout and move, clearfsimport is a viable option.
Simply set a view to the destination branch, and import the files found in the source (and wrong) view.
See "How can I use ClearCase to “add to source control …” recursively?"
That will checkout, add, modify or remove files in the destination view in order to mirror the ones from the source (here the source is a ClearCase view, but it could actually be any folder, ClearCase view or not, where the files are).
That will be enough to "recheck in the files on the proper branch", but that won't remove the versions from the wrong branch though, and I would advice against using cleartool rmver (even though I used that here).
Perhaps a subtractive merge is better.
If you know where they are, and where you want them, you could:
1) Merge the directory and files over.
2) Use cleartool ln in a view in the destination branch to link in the files, and then merge the files individually.
If you use clearfsimport, and don't purge the added-in-the-wrong-place files, you can set yourself up for down-the-road "fun" caused by "evil twins."
Personally, since you know the files and directories that got added, where, when and by whom, you could do something like this (command lines are off-the-top-of-my-head:
Get the list of files to copy/merge
cleartool find -type d -element "created_by(baduser) && created_since(25-Jul-2016) && !created_since(26-Jul-2016)" -print > dirlist.txt
cleartool find -type fl -element "created_by(baduser) && created_since(25-Jul-2016) && !created_since(26-Jul-2016)" -print > filelist.txt
Pull the directories over by merging the parent directories while CD'd/set in a view using the destination path. Not knowing the OS involved I can't say which way you would need to parse this. If you use perl, you can grab the offset of the last instance of the directory separator and use that in substr to get the parent directory path. In the windows command prompt, you can do something like this:
SET SRCDRIVE=D:
for /f "delims==" %x in (dirlist.txt) do cleartool co -nc %~px & cleartool merge -to %~px %SRCDRIVE%~px
for /f "delims==" %x in (dirlist.txt) do cleartool co -nc %~px & cleartool merge -to %~px\%~nx %SRCDRIVE%~px\%~nx
Yes, you can do all that in a single script, and do better error checking and not trying 40x to check out the same directory.
You might also be able to merge them to the 2.0 branch (using a view selecting the 2.0 branch). To identify the elements involved, you can run a 'cleartool find' command something like this:
% cd /vobs/myvob
% cleartool find -all -version 'brtype(1.0) && created_by(user_x)' -print
The 'created_since(date-time)' query might also be useful in the compound query.
Once you're convinced you have the right set of versions, you can use '-exec' in place of the '-print' to actually perform the merge. It might look something like this:
% cleartool find -all -version 'brtype(1.0) && created_by(user_x) && created_since(29-Jun)' -exec 'cleartool merge -to $CLEARCASE_PN -version $CLEARCASE_ID_STR'
If you're happy with the results, check everything in. Then you just have to decide if you need to remove the versions on the 1.0 branch (which you can do with another 'cleartool find ... -exec ...' command).
I am trying to use OpenCover With XUnit and MSBuild for our project and it works fine with one or two assemblies. But when the number of assemblies goes more than 2 it throws the below error:
EXEC : error : unknown command line option: MyProj.UnitTest.dll
[C:\CMR\Source\trunk\Build\Script\CMR.msbuild]
Committing...
No results, this could be for a number of reasons. The most common reasons are:
1) missing PDBs for the assemblies that match the filter please review the output
file and refer to the Usage guide (Usage.rtf) about filters.
2) the profiler may not be registered correctly,
please refer to the Usage guide and the -register switch.
Thought the problem would be with the 3rd assembly i added, so ran it individually again it worked fine. Below is the script I used:
<Exec Command='$(OpenCoverPath)\OpenCover.Console.exe "-target: $(XUnitPath)\xunit.console.exe" "-targetargs:C:\MyPath\UnitTest1.dll C:\MyPath\UnitTest2.dll C:\MyPath\UnitTest3.dll /noshadow" "-output:c:\OpenCoverReport\coverage.xml"'/>
And this is my assumption, for the purpose of posting here i had put paths of dll as C:\MyPath\UnitTest.dll but indeed the path is so huge and there are multiple assemblies with huge path. Does it has anything to do with this error?
try the -targetdir option of OpenCover
e.g.
<Exec Command='$(OpenCoverPath)\OpenCover.Console.exe -targetdir:"C:\MyPath" "-target: $(XUnitPath)\xunit.console.exe" "-targetargs:UnitTest1.dll UnitTest2.dll UnitTest3.dll /noshadow" "-output:c:\OpenCoverReport\coverage.xml" '/>
I've got my windows shell configured as displaying black text on a white background. This makes it almost impossible to read the default msbuild output due to the very pale colours (especially the yellow warnings).
Therefore I'd like to try one of the following, but I can't work out if it is possible.
I'd like to set a global setting to permanently turn off colourized output in msbuild; or
If (1) isn't possible is it possible to turn this output per-invocation (e.g. with command line arguments).
Does anyone know how to do one of the above?
In MSBuild 4.0 this is possible using the /consoleloggerparameters or /clp switch:
msbuild C:\some_path\your.sln /clp:disableconsolecolor
Alternatively, for previous MSBuild engines, this is possible using PowerShell:
Out-Host will display the default color:
Powershell -Command "msbuild C:\some_path\your.sln | out-host"
Write-Host will let you customize the colors:
Powershell -Command "msbuild C:\some_path\your.sln | write-host -foreground "white""
To completely disable colors use the /clp:disableconsolecolor option when invoking MSBuild.exe (for more information on the /clp option run MSBuild.exe /?).
Update as #KMoraz has commented, and updated his answer to, this only works with MSBuild 4.0 onwards.
If you want to disable color output you can also use the following (which will not work with MSBuild 4.0):
MSBuild.exe arguments > CON 2>&1
This got me curious ;-) so here is one more option that should work with all versions of MSBuild.exe and doesn't rely on CON redirection:
MSBuild.exe arguments 2>&1| findstr /r ".*"
Basically, what happens is that all lines of output are piped through findstr.exe since that uses a pattern to match "everything", all lines are simply output again, but loosing their attributes (color) information. In my tests the 2>&1 (redirect stderr to stdout) was not really necessary, as it looks MSBuild doesn't output any (colored) messages to stderr, but I added it for good measure.
The Story So Far
I've got a nice solution with a desktop application project, a few library projects, and a couple of development tools projects (also desktop applications). At the moment, my build server outputs all of the code into one OutputPath. So we end up with
drop-x.y.z\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
Helper.exe <-- developer tools
Grapher.exe
Parser.exe
... <-- the rest of the output
But, we're growing up and people outside of our team want access to our tools. So I want to organize the output. I decided that what we would want is a different OutputPath per executable project
drop-x.y.z\
Company.MainApplication\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
... <-- application specific output
Helper\
Helper.exe <-- developer tools
... <-- tool specific output
Grapher\
Grapher.exe
...
Parser\
Parser.exe
...
What I Did
I found this simple command. I like it because it retains all the Solution working-dir context that makes msbuild a pain.
msbuild /target:<ProjectName>
For example, from my solution root as a working directory, I would call
PS> msbuild /target:Helper /property:OutputPath="$pwd\out\Helper"
I'm testing this from PowerShell, so that $pwd resolves to the full path to my working directory, or the Solution root in this case. I get the output I desire.
However, when I run this command
PS> msbuild /target:Company.MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
I get the following error output (there's no more information, I ran with /verbosity:diagnostic)
The target "Company.MainApplication" does not exist in the project.
What I Need
The command fails on any project with a dot or dots in the name. I tried with many combinations of working directories and properties. I tried several ways of escaping the property values. I also tried running the command from a <Task> in a targets file.
I need to know either
A) How to fix this command to work property
B) How to achieve the same output with minimal friction
Try using an underscore as an escape character for the dot in the target parameter, e.g.
msbuild /target:Company_MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
Specify the target after the -target: switch in the format :. If the project name contains any of the characters %, $, #, ;, ., (, ), or ', replace them with an _ in the specified target name.
https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-build-specific-targets-in-solutions-by-using-msbuild-exe?view=vs-2019
Dan Nolan's answer and comments are correct. Just want to supplement the Microsoft documentation.
The /targets: switch is to identify a <Target to run in the project file. You need to supply your .csproj file as a an argument that is not prefixed by a /xx option marker.
You might also want to work based on the .sln file. In that case, you still dont specify the project in the .sln to build in this manner. I'll leave you to search up the correct syntax in case that's what you end up doing.