donet pack in VS Team Services - tfs

I have a problem with my build configuration in VS Team Services.
I try to mark my nuget packages with prerelease suffix.
I have a Utility CommandLine step defined.
Tool: dotnet
Argument: pack $(build.sourcesdirectory)/..../project.json --no-build --configuration Release --output nupkgs --version-suffix "prerelease-$(rev:.rr)"
I get the message:
"'1.0.0-prerelease-$(rev:.rr)' is not a valid version string."
If I do the same with a static:
Tool: dotnet
Argument: pack $(build.sourcesdirectory)/..../project.json --no-build --configuration Release --output nupkgs --version-suffix "prerelease-123"
That works fine.
So, it seams that the special placeholder $(rev:.rr) is not replaced, but I don't know why.
Kind regards

I found out that there are different variables for the build and release tabs.
I tried to use this token on a build definition, what didn't work.
I was able to achive what I want to do with a build token.
Kind regards

Related

The imported project Microsoft.WebApplication.targets was not found error while creating Docker Image using Docker file

I am trying to create Docker Image and while running Run dotnet build xxxxxx.csproj -c Release -o /app/build I am getting below error.
The imported project "C:\Program Files\dotnet\sdk\7.0.101\Microsoft\VisualStudio\v17.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\7.0.101\Microsoft\VisualStudio\v17.0\WebApplications\Microsoft.WebApplication.targets" is correct, and that the file exists on disk.
Can anyone suggest me the fix?
I got an answer
I was running wrong command to build a project based on ASP.Net framework 4.7.2.
Instead of using RUN DOTNET BUILD, I needed to use RUN msbuild command. It solved my issue. It is working now.

Why can't the dotnet cli 3.x build a docker image?

I've got a build script which was designed for dotnet 2.1. This script's job is to output a docker image that runs a dotnet core app. I recently made a small change to the dotnet core app but when I went to build a container, using my script, the image didn't work. I debugged this down to dotnet 3.1 behaving differently when calling the dotnet publish command...
Here is the command I'm using in dotnet 2.1:
dotnet publish WebService --configuration %CONFIGURATION% --output bin\Docker
This creates a Docker folder in the bin folder, as expected, but when I use dotnet 3.1 this output argument appears to be ignored.
I found this on the following on MSDN:
If you're using an SDK that is newer, like 3.0, make sure that your
app is forced to use the 2.2 SDK. Create a file named global.json in
your working folder and paste in the following JSON code:
{ "sdk": {
"version": "2.2.100" } }
https://learn.microsoft.com/en-us/dotnet/core/docker/build-container
So, after finding this info on MSDN that says that I need to force dotnet to use an older version, I now have a workaround but my question is... why? Dotnet 3.1 can't build Docker images? Please help me connect the dots on what I'm missing here.

How to ignore MSB4011 when running dotnet build

When I run dotnet build I get this warning many times:
C:\Program Files\dotnet\sdk\1.0.4\Microsoft.Common.CrossTargeting.targets(145,3):
warning MSB4011: "*.fsproj.proj-info.targets" cannot be imported again.
It was already imported at "Microsoft.Common.targets (127,3)".
This is most likely a build authoring error.
This subsequent import will be ignored.
[*.fsproj]
How can I prevent these warnings from displaying?
Add /nowarn:msb4011 to the command line.
dotnet build /nowarn:msb4011

CMAKE_MAKE_PROGRAM value cannot be retrieved from CMakeCache.txt

I have a project that I'm running through the Jenkins CI server and is being built using the Cmake plugin, and I am consistently getting the same error:
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/580152/Celero/build/64
ERROR:Failed to get CMAKE_MAKE_PROGRAM value from C:\Users\580152\Celero\build\64\CMakeCache.txt
I am using Visual Studio 2012, and I can build and run the .sln file in Visual Studio using the files generated by the Cmake plugin. However, it never builds or finishes whenever I use the Cmake plugin. I've worked with Jenkins a bit in the previous weeks, but I'm still a noob when it comes to some of the plugins and settings, and the same goes to Cmake.
Is this a Jenkins plugin problem, a Cmake error, or am I just not setting something up right/missing the problem entirely?
Any and all help is much appreciated.
Update:
I have found that this error is caused by Cmakebuilder plugin, and was updated to fix this issue in version 2.1, and though I'm currently using that version of the plugin the error is still occurring. Could something have happened that my version was not updated properly (though it says that no updates are available) or is this an issue with the plugin that must be resolved?
Thanks again for any help.
Perhaps my experience is old, but I have had trouble with the Jenkins cmake plugin. So I prefer to do my Jenkins cmake builds with a command shell batch script. This also makes the Jenkins build job more closely match my development build. I try to have my Jenkins build jobs be little more than
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=../exports ..
cmake --build . --config Release --target test
cmake --build . --config Release --target install

How do you build Xalan-C with Visual Studio 2010?

I can not find proof that it's possible. After 40 hours of driving myself to insanity, I'm left with a situation where I cannot build the Localization project that supposedly builds a header file needed by the poorly named AllInOne project (which builds Xalan-C.lib, natch).
This library is software malpractice writ-large, I am desperate for an answer because it is a dependency in another library that I have no alternative to using.
I have managed to build Xalan-C version 1.11, compatible with the latest version of Xerces-C (v3.1.1), in Visual Studio 2010. I don't know if it is possible with earlier versions, however these are the steps I followed in order to build with version 1.11:
Xerces-C has to be built as a dynamic library to obtain the xerces-c_3_1D.dll file which MsgCreator.exe is dependent on.
Clone the github repository to obtain the source code of Xalan-C version 1.11.
Set the environment variables XERCESCROOT and XALANCROOT in windows (not in Visual Studio).
XERCESCROOT The Xerces-C/C++ installation directory
XALANCROOT The Xalan-C/C++ source directory
Open the Xalan-C solution in VS2010 and build the MsgCreator project.
Copy the xerces-c_3_1D.dll file from the Xerces-C build and place it in the Xalan-C build folder, the same folder where MsgCreator.exe is located.
Now it is possible to generate the "missing" header files (LocalMsgIndex.hpp and LocalMsgData.hpp) that are needed to build the "AllInOne" project.
Run MsgCreator.exe in cmd with the provided path to XalanMsg_en_US.xlf which is located in $(XALANCROOT)\src\xalanc\NLS\en_US and what method to use when building the locale messages.
MsgCreator.exe $(XALANCROOT)\src\xalanc\NLS\en_US\XalanMsg_en_US.xlf -TYPE=inmem
(I used -TYPE=inmem, but check to see what method is best suited for your solution)
The header files are now generated and located in the build directory (where MsgCreator.exe resides). Copy or move them to $(XALANCROOT)\src and they should now be able to be located.
Now build the XalanMsgLib project.
And the last thing to do before the final build is to handle the including of afxres.h in the AllInOne.rc file (located in $(XALANCROOT)\Projects\Win32\Res\AllInOne). Visual Studio Express edition does not contain the MFC library which contains the afxres.h header. I simply changed it to #include "windows.h" instead.
And now it should be possible to build "AllInOne" successfully.
I struggled with this also and this is my recipe (VS2015 but look up the cmake docs for other IDEs)
Note I was specifically targeting xerces 3.2.3 and xalan 1.12. Use git tag to get the versions you need
git clone https://github.com/apache/xerces-c.git
cd xerces-c
git checkout v3.2.3
mkdir build
cd build
cmake .. -BVS2015 -G "Visual Studio 14 2015" -A x64 -DCMAKE_BUILD_TYPE=Debug
cd VS2015
devenv xerces-c.sln /Build Debug /Project ALL_BUILD
Because I use this with another build process that expects things in a certain way:
(assume you set up a target dir env called XERCESBUILD with bin/lib child dirs)
copy src\Debug\*.dll %XERCESBUILD%\bin
copy src\Debug\*.lib %XERCESBUILD%\lib
Then for xalan
git clone https://github.com/apache/xalan-c
cd xalan-c
git checkout Xalan-C_1_12_0
mkdir build
cd build
set PATH=%PATH%;%XERCESBUILD%\bin
cmake .. -BVS2015 -G "Visual Studio 14 2015" -A x64 -DCMAKE_PREFIX_PATH=%JBCRELEASEDIR% -DXALAN_DEBUG=1 -DCMAKE_BUILD_TYPE=Debug -DXerce
sC_LIBRARY_DEBUG=%XERCESBUILD%\lib\xerces-c_3D.lib
cd VS2015
devenv xalan-c.sln /Build Debug /Project ALL_BUILD
Note the xerces-c_3D.lib is specifically the Debug build so remove the D when doing the Release build.

Resources