When I publish my azure functions to azure not all of my referenced packages are being copied. I thus get an error stating that a specific file (Microsoft.CodeAnalysis.dll) cannot be found.
I have made sure that the package is referenced in my azure function project:
and have checked that it is in the .csproj file:
When I build locally the file is included in the \bin directory:
but when I publish to azure the file is missing:
This gives me run time error when the file is referenced:
How do I force the file to be included in the publish to azure, there is no option to "copy to output directory", or similar, in this instance in Visual Studio:
This problem is resolved in Azure Functions (.NET 5.0) but in .NET Core 3.1 use
<PropertyGroup>
<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
</PropertyGroup>
in the project file of Azure Functions as a workaround. Please find the details https://github.com/Azure/Azure-Functions/issues/1525
Related
I have a sql database project in Visual Studio (2019).
I am trying to deploy it via azure devops.
The pipeline is failing due to the below error:
##[error]C:\azagent\A1_work\r1\a_Transcripts-SQLDeployment\SampleDatabaseProject\SampleDatabaseProject\SampleDatabaseProject.sqlproj(117,3): Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk
The project builds without issue on my pc.
In the pipeline I have tried both the MSBuild and Visual Studio Build tasks, but the result is the same in each case.
Steps tried:
I found the reference in the sqlproj file xml, and removed it but this did not resolve the issue.
Appreciate any expertise on how to resolve this.
I have a strange behavior with msbuild on my Azure Pipeline.
I'm using Azure Pipeline with Self-hosted Windows agents.
Configuration:
My Visual Studio .sln contains two C# projects:
WebService (Rest API)
Business layer
In addition, the Business layer has dependencies on 2 others projects.
Kernel.DataModel
Kernel.DataAccess
The Kernel.DataAcess layer is using the NuGet package "Microsoft.SqlServer.Types" (14.0.314.76)
The Reference "Microsoft.SqlServer.Types" in the project Kernel.DataAccess has "Copy Local = True". Therefore the DLL file should be copied in the output (release) directory.
The problem:
When I run the Azure Build pipeline, the file "Microsoft.SqlServer.Types.dll" is not copied in the "_PublishedWebsites" directory.
To convince myself, I decided to run the same Pipeline on another build machine by changing the Agent Pool. At my surprise the DLL was present in the "_PublishedWebsites" on the second build machine.
Furthermore, I decided to manually run the msbuild command on my local computer and the the DLL was also present in the "_PublishedWebsites...\bin" on my local machine.
Log files:
I also looked at log files on the Build machines and on my local computer.
First build machine -> The DLL file is simply not copied !
Second build machine -> The DLL file is copied from this location.
Copying file from "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll" to "F:\AgentLatestBuild\A1\_work\28\b\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
Local machine ->
_CopyFilesMarkedCopyLocal:
Copying file from "C:\TFS\Repos\Src\Project\**packages**\Microsoft.SqlServer.Types.14.0.314.76\lib\net40\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\Microsoft.SqlServer.Types.dll".
Copying file from "E:\tfs\build\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
As you can see:
On the second build machine, msbuild is not using the NuGet packages folder but it's using "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll"
On my local machine, the DLL is copied from the NuGet packages folder.
Here are my questions:
How msbuild.exe is selecting the source/location of the DLL ?
Is there a way to force msbuild to first use the NuGet packages instead of any others folders ?
I think msbuild should first look in the NuGet packages folder and if the DLL is not found, then it should try to find it from somewhere else. (C:\Program Files (x86), GAC, etc..)
Finally, do you have any idea why the "Microsoft.SqlServer.Types.dll" is not copied at all on the first build machine. The DLL is present in at least three locations. (ie: NuGet packages folder, C:\Program files\ and it is also in the GAC).
It looks like msbuild is lost in the dependency tracking and can't find the file or it won't copy it for some other reasons.
Thanks for your help.
Is it possible that your *.csproj is targetting the wrong HintPath?
Could you check if you have something like this:
<Reference Include="Microsoft.SqlServer.Types">
<HintPath>..\packages\Microsoft.SqlServer.Types.YOURVERSION\lib\net40\Microsoft.SqlServer.Types.dll</HintPath>
</Reference>
thanks
I'm trying to create a pipeline in Azure DevOps and I get compilation errors caused by a missing reference:
[warning]C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5):
Warning MSB3245: Could not resolve this reference. Could not locate
the assembly "ABC". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation
errors.
I have a VS2017 solution with 2 projects.
ABC which is the actual application
ABC.UnitTests where I added some unit tests (I'm using MSTest)
When I build the solution locally, I'm able to do a successful build with the following steps:
Build ABC project => ABC.dll is generated
Add reference in ABC.UnitTests proj to ABC.dll
Build the entire solution => build successful
The .cs file in ABC.UnitTests references the application in this way, and generates the warning above:
using ABC;
If I do a clean build where ABC.dll is deleted and then I do a build of the entire solution I get the same MSB3245 warning. So the issue is reproducible locally if the dll does not exist.
Then, when I upload the solution to Azure DevOps, I do the following steps.
Upload the solution from local VS2017 and a project is created in Azure
Build the project in Azure DevOps => reference issue reported
I have a YAML config file with name azure-pipelines.yml which references the hosted 2017 agent.
pool: vmImage: 'vs2017-win2016'
Alternate flow:
Upload the solution from local VS2017 and a project is created in Azure
Comment out the reference to ABC.UnitTests project from the sln file
Create the pipeline => build successful.
You shouldn't refer any DLL as you mentioned in the comment.
The proper way is to refer to as a project. This way the DLL takes care of itself during the build
Proper way is
References -> (Right Click) Add References -> From that using Projects tab you can choose the Project which is generating that DLL(assemblies)
You can refer this SO
I'm trying to build my solution and package up the web app into a web deploy (.zip) package to be deployed.
I've added the Visual Studio Build step with the following MSBuild Arguments:
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)\"
And I've set up the Copy and Publish Build Artifacts step to copy all .zip files to the drop folder.
The build completes successfully but nothing is copied to the drop folder because there are no .zip packages that get created.
So when I look on the TFS server, the only thing in the 'a' folder is an empty 'drop' folder. And in the 's' folder is the solution directory with a PrecompiledWeb folder in it. Not sure what that is but it doesn't look like the deployment package (and it's not a .zip).
Any ideas?
I have tried the same on VS2015 MVC web application using VSTS and TFS 2015.2.1 both. I had to do a slight change to the Build arguments in Visual Studio build. That is removing the trailing "\" in /p:PackageLocation="$(build.artifactstagingdirectory)\".
Here is the argument I passed to Visual studio build step
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)"
Then I used Copy and Published Build Artifacts (Deprecated in VSTS you should use Copy task and Publish task instead of this task) as shown below
This gives me output as below.
First suggest you manually remote in the build agent and build the project through MSBuild command line with arguments to see if the project builds properly.
This will narrow down the issue is related to the environment on your build agent or your build definition.
You should directly use /p:PackageLocation=$(build.stagingDirectory
Besides since you have multiple assemblies that are referenced in the web app. Please also double check dependencies that are building in the correct order or referenced correctly.
Make sure the ASP.NET development workload of Visual Studio is installed.
If DeployOnBuild is having no effect, you may need to install the ASP.NET Development "workload" with the VS setup tool.
There are specific .targets files that, if they don't exist, cause these parameters to be silently ignored. Installing this adds those .targets and the parameters become active, allowing the .zip to be created.
For me (VS 2017) the relevant target file (or one of them, anyway) that was missing but is needed is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets
If it is missing, you'll need to install as above, and if it is there, then you have a different problem. ;)
I'm having some issues deploying an Azure WebJob using Visual Studio Team Services (VSTS).
The WebJob seems to be deployed successfully but it breaks the Azure website that is hosted in the same App Service! I don't have this problem if I deploy using VS2013.
This is my build task that generates the WebJob deployment package:
And this is my deployment task:
There are no errors when I deploy the Azure WebJob. If I go to the Azure Portal I see the WebJob is there, and it runs successfully. WebJob files are copied into the wwwroot\App_Data\jobs\triggered\RemoveExpiredDids folder as expected, but the problem is that some other files will be copied into the wwwroot\App_Data\bin folder, which will break the existing website that was already deployed into that App Service!!!
So I decided to find out why this was happening. After downloading and extracting the deployment package I saw there are 2 folders (app_data and bin) and the scheduler file (settings.job):
This explains why some assemblies are coppied into the wwwroot\App_Data\bin of the App Service. The strange thing is that this doesn't happen when deploying from VS2013!!! I took a look into the MSBuild log and found the following line:
Object dirPath ([app service name]\bin) skipped due to skip directive 'SkipBinFolderOnDeploy'.
Concluding, bin folder is included when deploying the Azure WebJob from VSTS but is excluded when deploying it from VS2013.
So my question is: how to prevent the bin folder from being deployed when using VSTS? Is there any MSBuild parameter/flag to do this?
I've had issue with this particular problem as well.
The latest method I found is using Web Deploy Operation Settings , -skip:Directory= (in this case it would be -skip:Directory='\\bin') when you create your azure deploy task in the release definition (Additional arguments). I've seen that this indeed excludes the bin folder from the update actions (result).
Let me know if this helps you in any way.
Refer to these ways to deploy webjob to azure:
Modify Visual Studio Build task to deploy webjob with FileSystem (MSBuild Arguments: /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\WebJob" /p:DeployDefaultTarget=WebPublish)
Add Delete Files task to release definition to delete bin folder (Source Folder: $(System.DefaultWorkingDirectory)/WebJobVnext/drop/WebJob); Contents:bin)
Modify Azure App Service Deploy task (1. Uncheck Publish using Web Deploy option. 2. Package or folder: $(System.DefaultWorkingDirectory)/[artifact name] /drop/WebJob)
I was finally able to fix it, thanks #starain-MSFT for pointing me in the right direction. I had to make some minor changes, though. This is the task that creates the deployment package:
MSBuild arguments:
/p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish /p:Configuration=$(BuildConfiguration) /p:OutputPath=.\bin\ /p:publishUrl="$(build.artifactstagingdirectory)\temp\WebJob"
The difference here comparing to #starain-MSFT answer is that I had to add the /p:OutputPath= parameter, otherwise I'd get the following error:
The OutputPath property is not set for project
After generating the package, I delete the bin folder and zip it (this reduces the build time).
This is my deployment task:
Please note that $(DeploymentPackagePath) is the path to the zip file that contains the deployment package, as mentioned before. It doesn't matter if you deploy the package as a zip file or if you unzip it and deploy the folder, it works both ways.