I'm trying to build and deploy an ASP.NET Core 2.0.3 Web API through TFS.
In Visual Studio I've configured Release to target the x86 platform.
I've also ensured the following in the csproj:
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<Platforms>x86</Platforms>
</PropertyGroup>
Building locally produces the expected output in folder bin\x86\Debug\netcoreapp2.0
Over in TFS I have a new .NET CORE build configuration with the restore/build/publish tasks. I notice that they don't use the standard BuildPlatform build variable which I've changed from Any Cpu to x86
Build: --configuration $(BuildConfiguration)
Publish: --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)
They only use BuildConfiguration which is either Debug or Release. This results in an Any CPU dll which will run as x64 on the release server.
I've tried adding -r win7-x86 to the publish command but this has resulted in a self contained deployment being published which isn't what I want.
I've tried adding -r win7-x86 to the build command, which results in the correct dll being produced, but the publish command does it's own implicit build and doesn't use the output of the previous build task.
How can I get TFS to publish an x86 DLL (framework dependent) for the web application?
For .NET Core applications (netcoreapp* - not ASP.NET Core on .NET Framework), the platform used during build usually doesn't matter.
The bitness is determined through the version of the dotnet.exe host that is used to load and run the application. E.g. C:\Program Files\dotnet\dotnet.exe (64 bit) or C:\Program Files (x86)\dotnet\dotnet.exe (32 bit).
The RuntimeIdentifier MSBuild property (what the -r switch sets) is only relevant for self-contained deployments but there is also an option to specify --self-contained false (=> SelfContained MSBuild property) so that a runtime-specific application is built without creating a self-contained deployment. This is typically only needed to filter runtime-specific assets - e.g. only include win-x32 versions of a SQLite native library instead of multiple versions for windows/linux/Mac etc. in a runtimes sub-folder.
Related
Travis CI recently added a Windows OS option to its build system. Unfortunately, the preinstalled packages only include Visual Studio 2017.
How can I build Visual Studio 2019 projects (such as .Net Core 3.1 and v142 build tools projects) on Travis?
The key to using updated build tools is Chocolatey, the Windows package manager. As long as the toolset is available on Chocolatey, you can install it on your Travis VM.
For .Net Core, that means installing the dotnetcore-sdk package.
For VC++ build tools, there is the visualstudio2019buildtools package, but note you will have to opt in to the Microsoft.VisualStudio.Component.VC.Tools.x86.x64 feature. See below for syntax. A full list of features is available in the Build Tools component directory.
Here's a full .travis.yml file for a VS 2019 solution containing a C++ project, a .Net Standard 2.0 project and a .Net Core 3.1 project. The test project makes use of the unmanaged DLL.
os: windows
language: cpp
env:
- MSBUILD_PATH="C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin"
install:
- choco install visualstudio2019buildtools --package-parameters "--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64"
- choco install dotnetcore-sdk
- dotnet restore
script:
- export PATH=$MSBUILD_PATH:$PATH
- MSBuild.exe -p:Configuration=Release -p:Platform=x64 CppProject/CppProject.vcxproj
- dotnet build --configuration Release
- dotnet test DotNetProject.Tests/bin/Release/netcoreapp3.1/DotNetProject.Tests.dll
I have to setup build process in Bamboo server. My requirements are,
We have a web-server application [more than 20 web projects, 10 windows service projects, DB scripts, some supported utilities like exe, xml's, code signing certificates, ssl certificates]
We have already build automation in c#, which uses NSIS scripts to generate installer.exe
Our build process has the following steps:
Checkout the source code
Checkout the Utilities
Checkout the NSIS installer source code
Update the source code
Update the Utilities
Update the Product versions in all the Assembly files of all the projects & Wix files
Build all the MSI projects based from the list [Project.xml] -> Once build completed with Code Signing post build CMD, then move to
some [ex: LatestPackage] folder in any [ex: Package] directory
Build all the Web app projects from the list [Project.xml] -> Publish into some [ex: LatestPackage] folder in any [ex: Package]
directory
Build all the support projects for installer from the list [Project.xml]
Copy the "LatestPackage" from "Package" directory to "LatestPackage" folder in "NSIS Installer" directory
Update the Installer source codes
Copy the installer custom assets to respective folder in "Installer" directory [SQL, some exe's]
Update Installer.xml file with the Branding information's in "Installer" directory
Compile Installer.nsi file & Installer package will be generated under Installer directory
Could anyone guide me in right path to achieve this.
1. Need to setup task for each and every projects?
2. Where to keep the files once build completed?
3. How to move the all the projects binaries into another projects directory?
4. How to keep the supported files and copy them to our source code folders?
5. How to maintain the generated build?
Is Bamboo Server Windows based? Can Visual Studio be installed on it?
If yes then you can automate building NSIS installers using MSBuild and Visual & Installer.
Also (if VS is present) there is an option to create NSIS project in Visual Studio and build the installer from it (building the solution from command line).
We have a mixture of ASP.NET Core and .NET Framework ASP.NET apps. We use a mixture of msbuild and dotnet to build the apps.
I'm trying to go all in on dotnet, but the build always throws an error of:
error MSB4019: The imported project "C:\Program
Files\dotnet\sdk\3.0.100-preview5-011568\Microsoft\VisualStudio\v16.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
Right now I'm just trying with a very simple command of dotnet msbuild foo.sln. No flags or anything being used for now.
I've tried this on multiple ASP.NET (not Core) apps and they all give the same error.
For ASP.NET Web applications, you need to compile using the following code.
C:\'Program Files (x86)'\'Microsoft Visual Studio'\[year]\[edition]\MSBuild\Current\Bin\msbuild.exe [project.csproj] /p:VisualStudioVersion=[version] /p:DeployOnBuild=true /p:PublishProfile=[profileName]
You can run in cmd or PowerShell.
Replace tags according to the version of Visual Studio installed on your machine and solution version.
For Example:
C:\'Program Files (x86)'\'Microsoft Visual Studio'\2019\Community\MSBuild\Current\Bin\msbuild.exe HelloWorld.csproj /p:VisualStudioVersion=16.0 /p:DeployOnBuild=true /p:PublishProfile=Release
We've solved the Microsoft.WebApplication.targets missing reference by adding it as a NuGet dependency, however the dotnet msbuild command still can't compile all related framework and asp.net projects.
We've also stood up our build server inside a docker container on an ubuntu image, as we were hoping to improve our infra with containerization etc.
However we've hit a wall in building all possible projects using the dotnet executable, even though it has the msbuild command built in.
Anyone had any luck with this?
This answer indicates this is not possible though
https://stackoverflow.com/a/66366638/6578823
I have created a asp.net mvc core app targeting the .net framework (not the multi platform core) as I want to include standard .net framework libraries and running cross platform is irrelevant to me as I will be hosting in Azure.
The solution looks like this:
I am trying to get a VSTS build working with this project (which is part of a larger solution) but when building I get the following error:
Which seems to be a common error. What should my build definition look like to build these .csproj based projects? There seems to be a lot of information but no definitive answer. Hopefully that answer can be here and people can stop looking elsewhere for information on how to get a Continuous Integration build going.
On a side note at the solution level I find no packages folder containing my nuget packages, why is this? The project definitely contains nuget packages.
Your project is using the newest MSBuild based project files for .NET Core.
The extension is still .csproj, but the XML schema is different than the ordinary .csproj used in .NET46 (and previous versions).
You need appropriate tooling to build such .csproj file, for example:
Visual Studio 2017: install it on your private build agent; VSTS hosted build agent does not have VS2017 installed yet;
.NET Core SDK 1.0.0-preview4-004233 (or more recent): this SDK contains the command line tool 'dotnet' for MSBuild .NET Core based projects.
Note in your build log that the msbuild used is the one shipped with VS2015 (version 14.0) instead, that does not support such .csproj format file.
On the other hand, if you do not need multiplatform nor any other benefit of .NET Core, why are you using it? Just created an ordinary ASP.NET 4 web project targetting .NET 4.6.
We are upgrading our TFS build system from 2012 to 2015, and are recreating our build machine. We setup the build service, installed necessary dependencies etc. The (legacy) XAML builds are working fine except for the following SGEN error:
SGEN: An attempt was made to load an assembly with an incorrect format: (location of compiled project .dll)
After much Googling and and reading a number of stack overflow articles, I am still at a loss. I referred to multiple pages including:
- SGEN: An attempt was made to load an assembly with an incorrect format
I have tried
Installing Windows SDK 8.1 (and 8.0), 6.1, SDK for Win Server 2008 .net 3.5
Installing .Net 3.5 to 4.6.1
Installing Visual Studio 2010, 2012, 2015
Changing the TFS Build XMAL template file setting MSBuildPlatform to x86 (Microsoft.TeamFoundation.Build.Workflow.Activities.ToolPlatform.x86)
Verified the Generate serialization stratgy setting is set to auto for all projects
Changed the Build definition MSBuildPlatform and 'configuration to build' settings to x86, but this generated multiple (unrelated) errors. Ultimately the compiled projects needs to run as x64.
Also
There is no sgen.exe in the C:/Program Files/.... although there are multiple in C:\Program Files (x86). I cannot confirm that there is an x64 version on the system at all, nor can I find where to install one.
Setting the build 'configuration to build' option to x86 is not an option: this needs to be compiled as x64
We are building a very large code base that is owned by a different team, so changing the .SLN or .csproj files is not really a good solution unless absolutely necessary.
The target platforms in the solution and project files were not correct. I believe in the process of resolving other issues, I had modified the project and solution files platform targets.
Since this upgrade was a trial run, we were able to run the upgrade again, which in effect rolled the code back to the last pre-upgrade set of code.