We have some projects that are only used in some environments so I would like publishing to skip them. However, when publishing the whole solution I get the following msbuild error:
"C:\Source\Solution.sln" (default target) (1) ->
"C:\Source\Project\Project.csproj" (default target) (51) ->
(ValidatePublishProfileSettings target) ->
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4253,5): error : The value for PublishProfile is set to 'Sta
ge', expected to find the file at 'C:\Source\Project\Properties\PublishProfiles\Stage.pubxml' but it could not be found. [C:\Source\Project\Project.csproj]
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4260,4): error : PublishProfile(Stage) is set. But the $(Web
PublishMethod) does not have a valid value. Current Value is "". [C:\Source\Project\Project.csproj]
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4267,5): error : Target ValidatePublishProfileSettings Faile
d [C:\Source\Project\Project.csproj]
Is there any way to ignore the project when publishing the solution so I don't get build errors?
I'd go with:
a custom build srcript (call msbuild individually for every project that you want to publish) (my preferred option hence it gives you much more flexibility)
a custom .sln file with only needed projects for the sole purpose of publishing (easier option, but harder to maintain)
3.Just a wild guess(never tried this for deployment, but should work based on my understanding) - you could try using Build -> Configuration Manager dialog in VS to uncheck build checkboxes for certain projects if you can go with creating separate solution configurations for separate deployment plans:
Related
After upgrading my WebApp from NET5 to NET6, when trying to push my WebApp to the Azure AppService, I get the NETSDK1152 error:
Found multiple publish output files with the same relative path:
C:...\src\ProjA_ViewImports.cshtml,
C:...\src\ProjB_ViewImports.cshtml,
C:...\src\ProjC_ViewImports.cshtml
The projects in Question are Razor Class Libraries (Project Sdk="Microsoft.NET.Sdk.Razor"), which all get referenced by a regular Web App (). The files in question are _ViewImport.cshtml files to contain common usings/imports for my Views. They only have their standard properties which never got changed by me (Action -> Content, Copy to Output Directory -> Do not Copy).
Before updating to NET6, everything worked flawlessly, both on my local machine as well as on Azure (both publishing and running the application). After my upgrade to .NET6, I started receiving the error mentioned above.
However, this ONLY occurs when I use the publish functionality (or when the CI/CD is triggered by pushing to the remote git repo). If I use dotnet publish locally, everything seems to be published just fine.
Trying the usual recommendation, of turning off the error (as proposed, for instance, here), did not solve anything for me.
Apart from either getting rid of the _ViewImport.cshtml files altogether, or restructuring the project, I am lost with regards how to potentially solve this issue while keeping the structure as is.
The .NET SDK (6.0.100 Preview 1) generates a new error (NETSDK1152) in cases where files from different source paths would be copied to the same file path in the publish output. This can happen when a project and its project references include a file with the same name that's included in the publish output.
Old Behavior
Both files were copied to the same destination. The second file to be copied overwrote the first file, and which file "won" was mostly arbitrary.
In some cases, the build failed. For example, when trying to create a single-file app, the bundler failed with an ArgumentException, as shown in the following build output:
C:\Program Files\dotnet\sdk\5.0.100-preview.5.20258.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(962,5): error MSB4018: The "GenerateBundle" task failed unexpectedly. [C:\repro\repro.csproj]
C:\Program Files\dotnet\sdk\5.0.100-preview.5.20258.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(962,5): error MSB4018: System.ArgumentException: Invalid input specification: Found multiple entries with the same BundleRelativePath [C:\repro\repro.csproj]
C:\Program Files\dotnet\sdk\5.0.100-preview.5.20258.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(962,5): error MSB4018: at Microsoft.NET.HostModel.Bundle.Bundler.GenerateBundle(IReadOnlyList`1 fileSpecs) [C:\repro\repro.csproj]
New behavior
Starting in .NET 6, MSBuild removes duplicate files that are copied to the publish folder if both the source and destination are the same. If there are any remaining duplicates, a NETSDK1152 error is generated and lists the files that are duplicated.
Reason for change
Duplicate files in the publish output sometimes caused build breaks or unpredictable behavior.
Recommended action
Ideally, you should update your project to avoid situations where multiple files with the same name are copied to the publish output. The error message includes the name of the duplicate file. Some causes for duplicate files include:
An ASP.NET Core project that references an ASP.NET Core web service, and each has its own appsettings.json file.
A project item where CopyToOutputDirectory is unnecessarily set to Always.
Binary log files can be useful for finding the cause of the duplicated files.
Alternatively, you can set the ErrorOnDuplicatePublishOutputFiles property to false.
I have configured a TFS(2017) build pipeline to compile a VS extension with debug mode for a specific requirement which require .pdb files.
The build solution task fails for "debug" configuration with below error, however same pipeline works for the release configuration.
I have tried the approach mentioned in the following discussion as well, howewer it doesn't resolve my issue.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/fd220999-5761-475a-bf86-98dff6b35218/unable-to-compile-vsix-project-that-is-a-part-of-my-solution-using-amd64-msbuild-from-vs2015?forum=msbuild
Appreciate if someone can help me to resolve this issue.
Following is the build configuration used for the Build Solution task:
Following build variables are used to configure build parameters.
Build Error message:
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets
(633, 5)
packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets(633,5):
Error VSSDK1077: Unable to locate the extensions directory. "Value
cannot be null. Parameter name: path1". Process 'msbuild.exe' exited
with code '1'.
Update your Microsoft.VSSDK.BuildTools NuGet package to latest version 15.9.3032, just in case it is a problem already solved.
Release configurations can also generate PDB files (Project properties, Build tab, Advanced...button, Output > Debugging information). So, if the Release configuration works for you, you can keep using it while also generating a pdb file with full debug information.
The error is happening when, once compiled correctly, the generated VSIX output file is going to be deployed to the folder for extensions of the experimental VS instance, which is a required step to debug the VSIX file. A possible explanation of the different behavior for Debug/Release configurations is that maybe your .csproj specifies <DeployExtension>False</DeployExtension> for the Release configuration. By default, if not set, that property is set to true in the Microsoft.VsSDK.targets file:
<DeployExtension Condition="'$(DeployExtension)' == ''">true</DeployExtension>
Since likely you don't need to deploy the VSIX to the VS experimental instance when building on a build server (because you are not going to debug it), you can set that property to False to skip the deployment. This can be done with a 3rd build configuration (ex: "DebugBuildServer"), for which you specify DeployExtension to False in the .csproj file, or sticking to two build configurations but passing the /p:DeployExtension=false in the MSBuild arguments of the Visual Studio Build task of your build pipeline.
I want to build a project with a particular named Build Configuration, let's call it Conf-A.
This is running as an MSBuild step on TeamCity. When the build runs, it spits out:
The OutputPath property is not set for project ... You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.
This project is part of a hulking great solution we load on our dev machines.
The error makes sense for my situation, since I'm building just the proj file, but I don't want to use the solution file since I'm trying break-up this monolithic app.
I want the build-server to treat this project as it's own component, even if for the moment it is part of a solution and has references to other projects (assemblies) in the solution.
Must I build this via a solution file?
I could potentially copy the solution file and prune off all the other projects that are not required, but that's more complexity.
(Maybe the error is a red-herring).
you dont need to build a sln. Its like the error says. You just havent specified a value for the variable OutputPath in your msbuild. You can add it to your files or you can pass it in at the cmd line - msbuild someproj.proj /p:OutputPath=C:\notallovermydrive
I am getting a strange error on the build server, this does NOT happen locally.
Error during file generation. The target file 'C:...\AcceptanceTest\Features\HelloWorld.feature.cs'
is read-only, but different from the transformation result. This
problem can be a sign of an inconsistent source code package. Compile
and check-in the current version of the file from the development
environment or remove the read-only flag from the generation result.
To compile a solution that contains messaging project on a build
server, you can also exclude the messaging project from the
build-server solution or set the msbuild
project parameter to 'true' in the messaging project file.
I'm not sure what to do to fix this, I don't have a "messaging" project (or know what is being referred too). And the code is the latest
This is the full message (some folder names have been obfuscated):
13>C:\Builds\2\Services\PService\src\packages\SpecRun.Excel.1.1.0\tools\TechTalk.SpecFlow-buildfix.targets(47,5):
error : Error during file generation. The target file
'C:\Builds\2\Services\PService\src\PService\Test\PService.AcceptanceTest\Features\HelloWorld.feature.cs'
is read-only, but different from the transformation result. This
problem can be a sign of an inconsistent source code package. Compile
and check-in the current version of the file from the development
environment or remove the read-only flag from the generation result.
To compile a solution that contains messaging project on a build
server, you can also exclude the messaging project from the
build-server solution or set the msbuild
project parameter to 'true' in the messaging project file.
[C:\Builds\2\Services\PService\src\PService\Test\PService.AcceptanceTest\PService.AcceptanceTest.csproj]
13>C:\Builds\2\Services\PService\src\packages\SpecRun.Excel.1.1.0\tools\TechTalk.SpecFlow-buildfix.targets(47,5):
error : Could not find file
'C:\Users\tfsbuild\AppData\Local\Temp\tmpPWithData.feature.xlsx.cs'.
[C:\Builds\2\Services\PService\src\PService\Test\PService.AcceptanceTest\PService.AcceptanceTest.csproj]
13>C:\Builds\2\Services\PService\src\PService\Test\PService.AcceptanceTest\Features\PWithData.feature.xlsx
: error : Generation error: Could not find file
'C:\Users\tfsbuild\AppData\Local\Temp\tmpPWithData.feature.xlsx.cs'.
[C:\Builds\2\Services\PService\src\PService\Test\PService.AcceptanceTest\PService.AcceptanceTest.csproj]
Delete HelloWorld.feature.cs from source control.
TFS will checkout files as read-only during a build and so SpecFlow fails to re-generate the file because it already exists and SpecFlow doesn't overwrite read-only files.
I created a new request for SpecFlow to not automatically add the file to source control here: https://github.com/techtalk/SpecFlow/issues/592
I'm not sure what the messaging project refers to, that's something I haven't seen before.
However the error reads as if the problem is due to an issue with the generation of the *.feature.cs from the *.feature file, but I am confused as to why this should be happening on the build server. Normally the generation of *.feature.cs occurs in the IDE when you save the *.feature file. This gets checked in and with some version control systems (VCS) you may end up with a read-only file status.
Your error reads as the build server is trying to re-generate the *.feature.cs file and cannot overwrite it.
Some things to check;
What VCS are you running? Does it leave checked-in files as read-only?
How are you building the files on the build server? Is there a custom step involved, or is it just a simple compile?
Can you replicate this error on your machine by setting the *.feature.cs to read-only and running the same build script on your local machine?
Good luck.
I'm receiving the below error, when I'm trying to build a solution file through CruiseControl and MSBuild version 4
ASPNETCOMPILER : error ASPRUNTIME: The precompilation target directory
Where does it come from and how to avoid it?
You need to double check the precompilation directory location.
You need either:
to delete its content (as in "ASPNETCOMPILER : error ASPRUNTIME: Target Directory not empty")
check if its path (Debug.AspNetCompiler.TargetPath or Release.AspNetCompiler.TargetPath in the solution file) is writable (for instance, you cannot write in the root directory of a dynamic view in ClearCase: M:\MyView)
check if the Cruise Control has access to your view (especially if it is a dynamic view)
As illustrated in "Trying to Build and Publish Asp.net website from command line using aspnet_compiler", the error message is usually more complete, similar to:
Error: error ASPRUNTIME: The precompilation target directory
(c:\Inetpub\wwwroot\WebsiteOne)
cannot be in the same tree as the source application directory
(c:\inetpub\wwwroot\WebsiteOne).
From the blog post "Getting Started with CruiseControl.NET":
For web solutions, update the TargetPath for the Debug and/or Release build of the application to be outside of the source application directory.
Otherwise, you will receive the following error:
ASPNETCOMPILER : error ASPRUNTIME: The precompilation target directory cannot be in the same tree as the source application directory.
This can be done by modifying the following in the solution file:
Debug.AspNetCompiler.TargetPath = “c:\ccnet\PrecompiledWeb\SampleWeb\”
Release.AspNetCompiler.TargetPath = “c:\ccnet\PrecompiledWeb\SampleWeb\”
Alternative, one may update the Output location found in the application MSBuild properties.
You may be wondering why an updated solution won’t be updated with the next scheduled build. As it works out (and makes sense) only changes which are applied to source control are pulled onto the build box.
I have resolved the issue by below changes:
Debug.AspNetCompiler.TargetPath = “c:\ccnet\PrecompiledWeb\SampleWeb\”
Release.AspNetCompiler.TargetPath = “c:\ccnet\PrecompiledWeb\SampleWeb\”
Right click on Project in Solution Explorer
Select Property Page
Select MSBuild Options on the left hand side of dialog box
Change path of OutputFolder - Make sure your path doesn't fall under same path tree