MSBuild.Sdk.SqlProj
MSBuild.Sdk.SqlProj copied to clipboard
'SDK Not Found' failure when building in Azure Pipeline - But everything works fine when ran locally
So, my understanding is that when we use the version-qualifier on the SDK tag in the project file, this causes the build to auto-magically go out and treat it like a package reference and find the dependency via NuGet.
<Project Sdk="MSBuild.Sdk.SqlProj/2.1.0">
When I work with my build locally (we're using Nuke and it's set to use dotnet build, not msbuild) this behavior appears to be working fine and I can build my solution and run all the steps in the Nuke build.
As part of my Nuke build, after compiling the solution I have a step that is enumerating over each project in the solution (using Nuke's own objects/types) and in that path I request an instance of the MSBuild project from the Nuke project so that I can then inspect the MSBuild properties (I'm looking for the 'IsTestProject' property in this case).
Oddly enough, it's when I'm doing this check that I see a failure in the Azure build pipeline where it's saying the database project SDK could not be found. The odd thing here is the actual step for compiling the solution was able to handle this - but that is likely due to configuring the database projects to not be built.
The build pipeline failure is coming out of MSBuild, as Nuke simply appears to be leveraging it when 'parsing a project'. And again, this is working locally so I'm not sure why there would be a difference when executing in the pipeline.
For the Nuke build, we are pointing the 'nuget sources' to use both the official NuGet feed -and- our own internal Azure DevOps feed and that is something we specify on the build/compile step; So that is really the only thing that comes to mind - but again the Nuke build runs fine locally and uses the exact same configuration & behaviors.
NOTE: In this case I have renamed the project to use the old naming (.SQLPROJ) but I verified this works locally so I don't believe that should be any factor here. The only other notable difference is that I do have the target framework pointing to .NET 6 now.
<TargetFramework>net6.0</TargetFramework>
Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'MSBuild.Sdk.SqlProj/2.1.0' specified could not be found. D:\a\1\s\src\XyzProject\Xyz.Database.sqlproj
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject[T1](IElementLocation elementLocation, String resourceName, T1 arg0)
at Microsoft.Build.Evaluation.Evaluator4.ExpandAndLoadImportsFromUnescapedImportExpressionConditioned(String directoryOfImportingFile, ProjectImportElement importElement, List
1& projects, SdkResult& sdkResult, Boolean throwOnFileNotExistsError)
at Microsoft.Build.Evaluation.Evaluator4.ExpandAndLoadImports(String directoryOfImportingFile, ProjectImportElement importElement, SdkResult& sdkResult) at Microsoft.Build.Evaluation.Evaluator
4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
at Microsoft.Build.Evaluation.Evaluator4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport) at Microsoft.Build.Evaluation.Evaluator
4.Evaluate()
at Microsoft.Build.Evaluation.Evaluator4.Evaluate(IEvaluatorData
4 data, Project project, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary1 environmentProperties, ILoggingService loggingService, IItemFactory
2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive)
at Microsoft.Build.Evaluation.Project.ProjectImpl.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
at Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(EvaluationContext evaluationContext)
at Microsoft.Build.Evaluation.Project.ProjectImpl.Initialize(IDictionary2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext) at Microsoft.Build.Evaluation.Project..ctor(ProjectRootElement xml, IDictionary
2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext, IDirectoryCacheFactory directoryCacheFactory)
at Microsoft.Build.Evaluation.Project.FromProjectRootElement(ProjectRootElement rootElement, ProjectOptions options)
at Nuke.Common.ProjectModel.ProjectModelTasks.ParseProject(String projectFile, String configuration, String targetFramework) in /_/source/Nuke.Common/ProjectModel/ProjectModelTasks.cs:line 150
Based on the feedback in #341 I reverted the filename suffix to .CSPROJ to see if that had any bearing on this issue but it did not. I still see the failure to resolve the SDK when trying to parse the project.
@bhehe I am also observing the same issue. By any chance, did you find any solution for it?
When running the pipeline, Observing issue: Unable to find package MSbuild.Sdk.SqlProj. But locally, it is fine.
@Shweta234 No luck on that front here. I'm not seeing any cause for why it wouldn't work and is behaving differently.
For now I've resorted to using a helper method "IsDatabaseProject" that is using naming conventions to classify the projects (unfortunately, I wanted to use the MSBuild Properties to drive it by real meta-data rather than conventions). When I encounter one I just skip over it.
fwiw - The Solution itself is building in the pipeline just fine even with the database project included since the solution configuration has it set to not be built in my case and when I compile I point to the solution. I was only bumping into this in build steps that followed the compilation step since I was using Nuke's project object and trying to get the 'real' MSBuild project for each in the solution so I could leverage the MSBuild properties to drive some logic.
@bhehe Got it. Thanks for the explanation. There is one more issue that i am observing which is somewhat similar to https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/issues/122. Could you please check and let me know.
@behe If you can provide a repro, I am happy to take a look at this, helping you without that is impossible.