I have an Azure DevOps GIT Repo with three different types of projects. Structure looks as follows;
Repository Structure
I have a Build Pipeline (Classic, not YAML) to build only the .Net Core Project as below.
Pipeline
The pipeline settings is pointed to consider only the NetCoreProject. The Restore, Build & Test tasks executes successfully. However, when it comes to the 'Publish' task the pipeline fails as it considers the entire repository (all projects) and not just NetCoreProject.
Actual cause of failure is in NetCPPProject folder there are some files without any extension (makefile, shortcut files, etc.) which the Publish task is not identifying and failing with below error.
##[error]Error: Failed find: ENOENT: no such file or directory, stat 'D:\a\1\s\NetCPPProject\inc'
Note: inc is a shortcut file (without any extension) and it is required to be present in the folder.
I tried following which did not work;
Added .artifactignore to ignore other folders but the .Net Core 'Publish' task seems not to consider that.
Tried specifying the arguments to Publish tasks to consider only the NetCoreProject .sln file and also .csproj file, but issue still occurs with same error message.
Reconfirmed the file exists in Build.SourceDirectory with a command line task.
Question is, how to make .Net Core 'Publish' task to exclude NetCPPProject and only consider NetCoreProject?
how to make .Net Core 'Publish' task to exclude NetCPPProject and only consider NetCoreProject?
To achieve this goal, you could try the following steps:
Step1: Disable Publish web projects option in Dotnet Publish task.
Step2: Set the target csproj file in Path to project field
For example:
Repo:
Result:
Related
On a Windows machine there is a GitLab-Runner run from a domain user with admin rights. When I log as this user and call dotnet build -c release to build an ASP.NET Core app, the dll has all the information from the AssemblyInfo.cs file. When I do the same as part of a CI job, the produced dll is missing all this information (for example the version number).
The AssemblyInfo.cs file is not part of the repository, instead, it is produced by a prebuild event (using gitWCRev.exe tool). However after running some tests I can see that the AssemblyInfo.cs is actually generated when the job is run by the runner.
Any help as to why the file is ignored and how to overcome this issue would be appreciated.
At first I thought that this might be related to Pre-build task of Visual Studio project fails in GitLab Runner issue, but I don't get any build errors.
On the same machine, I build a .Net Framework app which has the same AssemblyInfo setup, but is compiled using msbuild /property:Configuration=Release by the runner and the produced dll file has all the expected information.
It turns out the problem was partially related to the AssemblyInfo.cs file not being part of the repository.
SDK-style csproj normally don't list the files in the project, but figure them out based on the folder contents. When dotnet build was run, AssemblyInfo.cs wasn't present in the project directory (GitLab-Runner usually clears out files not present in the repository before starting a job/pipeline), so build tools had no idea they needed to load it. It made no difference that the file was being created by the build tools.
The solution proved to be creating an empty AssemblyInfo.cs file before running dotnet build. This way build tools knew they needed to compile it. Actual compilation still happened after prebuild events, so all the needed information was there.
I created the empty AssemblyInfo.cs file using PowerShell:
New-Item -Path "Properties/AssemblyInfo.cs" -ItemType File
Also, checking the build logs helped me finally figure it out. To get the build logs I've called build tools like this:
dotnet build -c release /flp:v=diag
The .Net Framework app didn't have this problem because it wasn't an SDK-style project. All the files needed for compilation were listed in the project file and build tools knew to load them, even if they were created during the prebuild event.
Iam trying to push my asp.net(mvc) code azure devops using Git bash, but I am getting VSBuild error saying:
Error: Preparing the test sources file failed.
Error: No test sources found matching the given filter '**\*test*.dll,!**\*TestAdapter.dll,!**\obj\**'
VsTest task failed.
That error should be separate from a git push.
Meaning:
you are pushing your sources
but your Azure pipeline might not be correctly configured
See this thread for instance:
From this error (No test sources found matching the given filter '**\*,!**\obj\*'), we can see that you release pipeline do not get the build Artifacts sources.
So you need add a "Copy Files" task before your publish task in the build pipeline:
Or add a "Copy Files" task before your "VsTest" task in the release pipeline.
If it still an issue for you, please share your Organization name and log in account.(please choose "viewable by Microsoft Only")
See also "Publishing test assemblies with artifacts in order to use them during functional tests on VSTS", and this thread, which illustrates a correct pipeline configuration:
From the error we know that Vstest task failed to find the test assemblies.
It may because the test files you defined in Test Files field is incorrect, or you specified a wrong search folder where the test assemblies are not exist. For below example. Vstest task will search for all the files that matching *test*.dll in folder $(System.DefaultWorkingDirectory)(eg. c:/agent/_work/1/s). Check here to find more predefined variables.
The fix is simple if you know where the test assemblies is copied by VsBuild task. You can check the log of Visual Studio Build task, to find out where the test.dll files are located.
Hope you find above helpful.
I have a web app in dot net along with other projects. when i open the .sln file and publish the web project, it does. But, when I try to publish the web proj using command line and .csproj, it gives an error. "Nothing to do. None of the projects specified contain packages to restore."
I got this after converting my csproj to vs2019 format and running dotnet test. The solution was to ensure i had the right test adapter and framework. My csproj files had both the old Microsoft.VisualStudio.QualityTools.UnitTestFramework reference and the new MSTest.TestAdapter + MSTest.TestFramework + Microsoft.NET.Test.Sdk.
I kept the new ones and my tests were run.
I had this problem in a batch file I use to build a UWP component for release. The build command is
%MSBUILD% CartoType\src\main\single_library\uwp\CartoType\CartoType.sln -p:Configuration=Release;Platform=x64
where %MSBUILD% is the full path to msbuild. I first added an msbuild command with the -t:restore option and got the message reported by the original poster ('Nothing to do. None of the projects specified contain packages to restore').
The solution was to add this command before the command given above:
%MSBUILD% CartoType\src\main\single_library\uwp\CartoType\CartoType.sln -p:RestorePackagesConfig=true -t:restore
I have a solution with many projects. Some target frameworknetcoreapp2.1, some other target framework netstandard2.0 and one project has a double target framework
<TargetFrameworks>netstandard2.0;net471</TargetFrameworks>
I'd want to have a artifact for win10 with a single command:
dotnet publish MySolution.sln -c Release -o "targetFolder" -r win10-x64
With this command I have this error while building the project with double target framework. Here's the errors:
C:\Program Files\dotnet\sdk\2.1.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.CrossTargeting.targets(31,5) error : The 'Publish' target is not supported without specifying a target framework. The current project targets multiple frameworks, please specify the framework for the published application.
The error is clear. At the end I find that dll compiled in the output directory and it seems like it is a netstandard2.0 dll because my application still works.
I don't like dirty things so, how can I solve my problem?
I would avoid to call N times the "dotnet publish" command if possible.
Don't use dotnet publish with the same output directory on a solution. Especially not with the "-r" argument.
It is dangerous because:
libraries don't have the right trimming behaviour for netstandard facade packages
libraries may have odd behaviour when publishing with "-r", especially for netstandard<2.0 dependencies. (they'd end up copying the .NET Core 1.0/1.1 implementation(!) assemblies)
you may end up with different NuGet dependencies in the output (transitive dependencies)
Copy-to-output/publish-directory items may end up overwriting each other, it may even lead to build failures
Call it individually for all application (console app, web app) projects or create an MSBuild file that publishes these applications.
I have a ASP.NET Webforms Website project(note this is NOT WebApplication project i.e. there is no .csproj).
I want to do a auto deploy, file system to our network share.
I created a profile and so there is website.publishproj file and profile xml.
I tried adding this in MSBuild arguments in Build Definition:
website.publishproj /p:DeployOnBuild=true
/p:PublishProfile=MyDevProfile /p:VisualStudioVersion=12.0
I get this error:
MSBUILD : error MSB1008: Only one project can be specified. Switch:
website.publishproj
Any idea what am I doing wrong? I believe this has something to do with Website project type.
This is something I read: How to use command line msbuild to deploy VS2012 Web Site project without precompiling it?
Here is the command:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo
/noconsolelogger
"E:\Builds\1\TP1\MyWebsite_Dev\src\Websites\MyWebsite\MyWebsite.sln"
/nr:False /fl
/flp:"logfile=E:\Builds\1\TP1\MyWebsite_Dev\src\Websites\MyWebsite\MyWebsite.log;encoding=Unicode;verbosity=normal"
/p:SkipInvalidConfigurations=true website.publishproj
/p:DeployOnBuild=true /p:PublishProfile=DropToDemoProfile
/p:VisualStudioVersion=12.0 /m
/p:OutDir="E:\Builds\1\TP1\MyWebsite_Dev\bin\"
/p:VCBuildOverride="E:\Builds\1\TP1\MyWebsite_Dev\src\Websites\MyWebsite\MyWebsite.sln.vsprops"
/dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation
Server
12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/35;IgnoreDuplicateProjects=False;InformationNodeId=13;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;LogWarnings=True;TFSUrl=http://mytfs:8080/tfs/colletionname;"*WorkflowForwardingLogger,"C:\Program
Files\Microsoft Team Foundation Server
12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;"
/p:BuildId="7d23530d-7349-406f-98b7-5d4f0b9f4101,vstfs:///Build/Build/35"
/p:BuildLabel="MyWebsite_Dev_20141122.13" /p:BuildTimestamp="Sun, 23
Nov 2014 01:22:05 GMT"
/p:BuildSourceVersion="LMyWebsite_Dev_20141122.13#$/TP1"
/p:BuildDefinition="MyWebsite_Dev"
You're trying to build the solution (MyWebsite.sln) and the project (website.publishproj) simultaneously as part of the same MSBuild command at least according to the arguments being passed.
You can run msbuild website.publishproj /pp:website.pp.publishproj to see what targets you can call in website.pp.publishproj or what properties to override.
You can run set MSBUILDEMITSOLUTION=true && msbuild MyWebsite.sln to see what targets you can call in MyWebsite.sln.metaproj and MyWebsite.metaproj or what properties to override.
Your DeployOnBuild command is fine and should work, I'm guessing your TFS build config is pointing to the .sln and passing website.publishproj as an argument rather than the primary target of the build, so either repoint it to build the .publishproj directly or... well, there doesn't seem to be any alternative, you can try adding a new configuration and editing the .sln with new AspNetConfiguration and MyDevProfile.AspNetCompiler.TargetPath but then you're just asking for trouble.
You need to upgrade your Web Site to a Web Application in order for any of this to be automatic.
Its a fairly simple procedure and even on sites with thousands of pages I have completed the migration in only a few days of one persons time without impacting other devs.
Web Site functionality has been feature complete for over 10 years. While it still existing in the product for back-compat I would not recommend using it.