get source from downloads
make && make install
mkdir -p -- /usr/lib/mono/xbuild/Microsoft/Portable/v4.0
/usr/bin/install -c -c -m 644 targets/Microsoft.Portable.Common.targets /usr/lib/mono/xbuild/Microsoft/Portable/v4.0/Microsoft.Portable.Common.targets
/usr/bin/install: cannot stat `targets/Microsoft.Portable.Common.targets': No such file or directory
the mono 3.4 archive is missing a file named Microsoft.Portable.Common.targets which should be located at path mcs/tools/xbuild/targets/Microsoft.Portable.Common.targets with the following content:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\Microsoft.Portable.Core.props" />
<Import Project="..\Microsoft.Portable.Core.targets" />
</Project>
See this bug:
https://bugzilla.xamarin.com/show_bug.cgi?id=18690
Just a small note (as much for my self) which I made a mistake with as the path specified I found a little confusing. If you installed in extracted in /usr/local/src/mono-3.4/ the path of the file you need to put the content in is:
/usr/local/src/mono-3.4/mcs/tools/xbuild/targets/Microsoft.Portable.Common.targets
not
/usr/local/src/mono-3.4/mcs/tools/xbuild/targets/.content/Microsoft.Portable.Common.targets
or
/usr/local/src/mono-3.4/mcs/tools/xbuild/targets/.content
Related
What Condition Expression for PropertyGroup/ItemGroup should be used to differ target OS (-r argument of dotnet publish)? E.g. on these commands:
dotnet publish -c Release -r win-x86 --self-contained false
dotnet publish -c Release -r linux-arm --self-contained false
Currently I've forced to use different Configurations and build using these commands:
dotnet publish -c ReleaseWin32 -r win-x86 --self-contained false
dotnet publish -c ReleaseLinux -r linux-arm --self-contained false
I know that MSBuild can define even target .NET Core/Framework version (e.g.Condition="'$(TargetFramework)' == 'netcoreapp3.1'"), so probably should also define target OS (something like Condition="'$(TargetOS)' == 'win-x86'").
Does there may be somehow used direct detection of target OS in CSPROJ file without using -c ReleaseWin32 / -c ReleaseLinux for builds for different platforms? Shortly, does MSBuild syntax have any Condition about target OS?
The CLI's -r linux-arm translates to MSBUild -property:RuntimeIdentifier=linux-x64 so you can use $(RuntimeIdentifier) in conditions:
<PropertyGroup Condition="'$(RuntimeIdentifier)' == 'linux-arm'">
</PropertyGroup>
<ItemGroup Condition="$(RuntimeIdentifier.StartsWith('win'))">
</ItemGroup>
I Have a file move event which I want to trigger after a publish
<Target Name="CopyEmailTemplates" AfterTargets="AfterPublish">
<ItemGroup>
<TemplatesFolder Include="Views\EmailTemplates\*.cshtml" />
</ItemGroup>
<Copy SourceFiles="#(TemplatesFolder)" DestinationFolder="$(OutDir)Views\EmailTemplates\" />
</Target>
I've confirmed that the command does not return the publish directory with this target:
<Target Name="OutputTest" AfterTargets="AfterPublish">
<Exec Command="echo OutPath: $(OutputPath)" />
<Exec Command="echo OutDir: $(OutDir)" />
</Target>
Expected:
OutDir is set to dist/
Actual behavior:
OutDir is set to bin/Release/netcoreapp2.0/
I am using: .NET Command Line Tools (2.1.4) on osx.10.12-x64
Publish is a two-step process. The project is built using normal build settings and then published to $(PublishDir). Use this property wherever you need to know the path of the publish output.
Self answering in hopes to prevent future headaches for people.
The dotnet publish -o ./dist command will set the $(PublishDir) variable in msbuild.
dotnet build -o ./dist does however set $(OutDir)
To be more explicit with our build I now use the msbuild command
dotnet publish -o ./dist -c Release
Becomes:
dotnet msbuild /t:publish /p:PublishDir=dist/ /p:Configuration=Release
We were on SVN 1.6.11 and just upgraded to 1.8.8 today. We can check files in and out using https:// and file://
Our install of WebSVN 2.3.3 was working before, but now give a blank page with this error:
XML error: no element found (3) at line 3 column 0 byte 28\ncmd: svn --non-interactive --config-dir /tmp log --xml --verbose -r HEAD:1 'file:///home/ckhronos/svn/repos/#HEAD' --limit 2
If we run:
svn --non-interactive --config-dir /tmp log --xml --verbose -r HEAD:1 'file:///path/to/repos/#HEAD' --limit 2
from the command line we get a reasonable output:
<?xml version="1.0" encoding="UTF-8"?>
<log>
<logentry
revision="26184">
<author>authorname</author>
<date>2014-04-02T16:09:30.683040Z</date>
<msg>Short message.
</msg>
</logentry>
<logentry
revision="26183">
<author>authorname</author>
<date>2014-04-02T15:46:03.903486Z</date>
<paths>
<path
prop-mods="false"
text-mods="true"
kind="file"
action="M">/path/to/file/edited.txt</path>
</paths>
<msg>Long message here</msg>
</logentry>
</log>
We are running CentOS 6.5 with PHP 5.4. We build subversion from source. Would anyone know why we might be getting this error?
There were two version of SVN on the server. One was the old 1.6.11 in /usr/bin/svn and the other the new 1.8.8 version at /usr/local/bin/svn. From the command line I was getting out put from the new /usr/local/bin/svn version. In PHP, where that command was run from, it was loading in the old version of svn.
Once I updated the path to point to the proper version of svn, all was fine.
Incidentally I found this bug by using:
echo stream_get_contents($pipes[2]);
To see what the real output was from the script.
This is getting rather maddening - I'm trying to build an RPM out of some BASH scripts which work as Nagios plugins. I keep getting:
error: Installed (but unpackaged) file(s) found:
/usr/lib64/nagios/plugins/netappassigncheck
/usr/lib64/nagios/plugins/netappassignprep
In the %files directive of my spec file I have tried most of the combos that have been suggested here and on various other internet forums:
/usr/lib/nagios/plugins/*
/usr/lib/nagios/plugins/netappassigncheck
/usr/lib/nagios/plugins/netappassignprep
%dir /usr/lib/nagios/plugins/
And currently I am on
%dir %{_libdir}/nagios/plugins/
This is why my most recent error output is lib64, previous errors when quoting the full path were /usr/lib/...
These are the only 2 files that should make up the package as well.
Here is my .spec file
Name: netappautoassign
Summary: A set of Nagios Plugins for automatically assigning disks to a Netapp
Version: 1.0
Release: 1
License: %{license}
Group: Applications/System
Source: %{source}
URL: Reserved
Vendor: %{vendor}
Packager: %{packager}
BuildArch: noarch
Requires: bash, grep, util-linux, coreutils, expect, openssh-clients, bc, sed
Provides: netappassignprep, netappassigncheck
%description
Since Netapp's autoassign function may lead to disks being assigned to the
wrong head these NAGIOS plugins will ensure disks are added to the correct
head when replaced.
%prep
%setup -q
%build
%install
rm -rf %{buildroot}
install -d %{buildroot}%{_libdir}/nagios/plugins
cp netappassigncheck %{buildroot}%{_libdir}/nagios/plugins/
cp netappassignprep %{buildroot}%{_libdir}/nagios/plugins/
%files
%defattr(755,root,root,755)
%dir %{_libdir}/nagios/plugins/
%clean
rm -rf %{buildroot}
%post
And here's my ~/.rpmmacros
%_topdir %(echo $HOME)/rpmbuild
%_tmppath %{_topdir}/tmp
%buildroot %{_tmppath}/%{name}-%{version}
%license RESERVED
%source %{name}-%{version}.tar.gz
%vendor REDACTED
%packager REDACTED
EDIT - SOLVED
I'm not sure if this is a bug or desired behaviour, but it would appear that during the build setion the %{buildroot} variable was not being read in from .rpmmacros Having moved this variable into the main spec file the RPM is now built.
I'm not sure if this is a bug or desired behaviour, but it would appear that during the file verification section, it was reading in all the current active plugins under the root file system and not the %{buildroot}.
I suspected that the %{buildroot} variable was not being read in from .rpmmacros at this stage, although it was for all other stages.
I moved the declaration of %{buildroot} into my main .spec file and the build is now working!
I am using following command to install a service via MSBuild file. This works great
<Exec Command= 'c:\test\myService.Appservices.exe install' ContinueOnError='false' />
But the above command install the service on local machine. I want to install the service on a remote machine. How can I specify the machine name using this command?
As per Mike Vine's comment, MSBuild doesn't include tools for remote execution. You could however use something like psexec. e.g.
<Exec Command='psexec -accepteula -s \\RemoteServer "C:\Path To EXE on Remote Machine\my.EXE"' IgnoreExitCode="false" ContinueOnError="false" Timeout="600000" >
<Output TaskParameter="ExitCode" PropertyName="exitCode1"/>
</Exec>