Could not locate the assembly "Microsoft.SqlServer.TransactSql.ScriptDom"
We have vanilla build agents so would have to either install these independantly or include them in source control.Do you have any other suggestions, by that I mean is there an alternative way to reference these libraries using some sort of Nuget bearing in mind you can't currently reference nuget packages in .sqlproj?
Best Answer
-
G4734 Posts: 6 New member
Hi Eddie,
Thanks again for looking into this for us,
We managed to find a work around, for what we are trying to do which is to use the latest SQLCover within our SqlChangeAutomation database project build without SQLCover.dll being stored in SourceCode. Normally (.Net) you could create a dependency using the NuGet Package Manaer within the project but because SqlChangeAutomation projects in Visual Studio are based on .sqlproj projects and these type of projects don't allow you include NuGet dependancies, we had to look at a different way:Solution was to include a package.config
<?xmlversion="1.0" encoding="utf-8"?>
<packages>
<package id="GOEddie.SQLCover"version="0.5.0" targetFramework="net461" />
</packages>And then to add the following to .sqlproj file
<ItemGroup>
<PackageReference Include="GOEddie.SQLCover" Version="0.5.0" />
</ItemGroup>We then add a NuGet Restore task in the build pipline pointing it at the package.config and this seems to do the required job
Answers
Are you using LocalDB or specifying a SQL Instance?
If using LocalDB does your project include features that are not supported by localDB?
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
We are using a specific Enterprise SQL instanace specially provisioned for SQL builds, as far as I can see the project builds so I'm not 100% sure why - during the build - this warning is appearing?
I would assume that this warning would be more appropriate when I'm actually running the tests and code analysis which is the next step in the ADO pipline. It's at this stage that I'm trying to figure out how we get these libraries onto the build machine which does not nativley have them installed?
I attempted to find further information.
I believe this problem is in regards to LocalDB supplied in Visual Studio. In that it could be a reference to an earlier version of LocalDB where a later version is required.
What version of Visual Studio are you using?
Are you able to provide the full error message, which hopefully include the version number and other details?
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
Hi Eddie,
Thanks again for looking into this for us,
We managed to find a work around, for what we are trying to do which is to use the latest SQLCover within our SqlChangeAutomation database project build without SQLCover.dll being stored in SourceCode. Normally (.Net) you could create a dependency using the NuGet Package Manaer within the project but because SqlChangeAutomation projects in Visual Studio are based on .sqlproj projects and these type of projects don't allow you include NuGet dependancies, we had to look at a different way:
Solution was to include a package.config
<packages>
<package id="GOEddie.SQLCover"version="0.5.0" targetFramework="net461" />
</packages>
And then to add the following to .sqlproj file
<PackageReference Include="GOEddie.SQLCover" Version="0.5.0" />
</ItemGroup>
We then add a NuGet Restore task in the build pipline pointing it at the package.config and this seems to do the required job