ReadyRoll 1.15.17333.6745 - November 29th, 2017 - Broke our VSTS ReadyRoll Project Build

rbigbie

The other day I upgraded my ReadyRoll in Visual Studio 2017 to 1.15.17333.6745 - notice the SQL Compare Engine update in the release notes, and committed my changes, and pushed my code into our VSTS which uses CI and our build is kicked off. My build now consistently fails and the error is: Error : An error occurred while attempting to generate a deployment preview report: The database snapshot was saved by a newer version of SQL Compare.

I need to know how to fix this. And need help from the ReadyRoll Support team. The Redgate ReadyRoll VSTS extension we currently have installed is version 2.1.2. I am not sure if there is an incompatibility between these two now that the SQL Compare Engine has been changed in the last 1.15.17333 release.

Please advise, I appreciate it. Anyone else having this problem? If so what did you do to fix it? Thank you!

dnlnln

Thank you for confirming that you are not actually using the NuGet package. From your build log, I can see that the current version of ReadyRoll is being used in your VSTS build:

Using ReadyRoll toolpath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\ReadyRoll\ReadyRoll.Data.Schema.SSDT.targets

This is the version of ReadyRoll that currently ships with Visual Studio 2017, which is installed on the built-in VSTS build agent, is the version that is used rather than the version of the ReadyRoll VSTS marketplace extension itself.

In order to ensure consistent results between your development machine vs your build agent, may I recommend embedding the ReadyRoll.MSBuild NuGet package into your solution (see Option C on this page for more information). This should subsequently resolve the error you received earlier.

In terms of the cause of the error: it appears also that the database may have previously been deployed outside of VSTS (e.g. from a development machine) with a newer version of ReadyRoll, which may have resulted in a later version of the schema snapshot being stored in the target database. As the error was raised from a non-essential part of the build process -- the report generation engine -- rather than the package deployment process, we will review the way that such exceptions are being handled in the product to see if these might be better treated as compiler warnings.

dnlnln

Sorry to hear that you've run into a problem with building your project.

Would you mind retrieving the version of ReadyRoll currently being used by your build? (this may be different to the Visual Studio version if you have installed the ReadyRoll.MSBuild NuGet package into your solution, for example).

The version of ReadyRoll being used during build can be determined by looking for the following string within the output log:

Using ReadyRoll version: <VersionNumber>

If the version does not match, then it is possible that an upgrade of the build engine NuGet package is required. Please see this article for upgrade steps.

If after upgrading the package the issue is still is not resolved, would you mind sending a copy of the build output from Visual Studio, as well as the log from your VSTS build, and send it to our support team, mentioning this forum post so that we can investigate it further. In the meantime, running the following query on the target database should work-around the problem, preventing build failure from continuing to occur:

USE [<DatabaseName>];
DELETE FROM [dbo].[__SchemaSnapshot];
GO

Please note that, once the query is executed, deployment preview and drift reporting will be skipped until such time as the next deployment is performed to the target server/database.

rbigbie

Thank you for your fast response. On my Visual Studio 2017 development machine, which uses the VS ReadyRoll Extension, I see Using ReadyRoll version: 1.15.17333.6745. In our VSTS Build Logs I see Using ReadyRoll version: 1.14.19.5869.

We do not use any ReadyRoll NuGet packages. We only use the Visual Studio 2017 ReadyRoll 1.15.1733 Extension and the Redgate ReadyRoll VSTS extension version 2.1.2. So regarding the NuGet stuff, I am not sure what you are referring to.

I have gone ahead and opened up a support ticket with the supporting information they will need to review this issue. Thank you for your help.

rbigbie

Hi Daniel,

I reluctantly went ahead and pursued Option C – Use the ReadyRoll.MSBuild NuGet package located on this page: https://documentation.red-gate.com/rr1/installing/build-components based on your response.

It appears to work and I do not receive the VSTS Build error anymore. I do have to say though that I am disappointed that I had to move from Option A - In VSTS/TFS, use the ReadyRoll build definition template to Option C just because of an upgrade in the product. I feel the proper solution would have been to be able to update the Build Agent with the newer software version (which I have no idea how it gets updated). I am not sure why it didn't get updated automatically and throughout all these comments I haven't seen any response as to why it wouldn't have, even though in previous upgrades it had.

None the less, I appreciate that there was a solution that worked in which your presented us with. Thank you for all the help you gave us regarding this issue.

dnlnln

I'm sorry for the inconvenience caused by the installation of the NuGet package.

Unfortunately this is necessary due to the fact that we do not have control over updates to the build agent image. The inclusion of ReadyRoll within the build agent is made through upgrades to Visual Studio 2017; we regularly supply new updates to Microsoft, however the Visual Studio team operate on a different testing and release cadence to us. So there will always be a lag between publishing of new versions of the extension directly by us and the shipping of the version within the version of VS used within the build agent.

With regard to Option A, just to confirm this actually requires the following additional tasks to be included in your build configuration:

If you are building a ReadyRoll project in VSTS/TFS, the ReadyRoll build components will be installed to your build agent automatically using two build tasks: NuGet Tool Installer and ReadyRoll Download Build Components.

If you have a custom build definition, just add these two tasks before the Visual Studio Build task.

If these tasks are not configured, then the version built into VS2017 that I mentioned before will be used. If you already had these tasks configured, yet the build continued to use the older version, please let me know so this can be investigated.

However for your configuration/environment, using Option C (NuGet package) should help ensure consistent results between your desktop development+deployment experience vs your VSTS deployments.

rbigbie

Hi Daniel,

I did notice that I didn't have those two tasks in our VSTS build configuration when you replied the first time. So instead of wasting your time, I added them and ran the build again, but with the same error and older version before I replied back to you the first time. So to answer your question: "If these tasks are not configured, then the version built into VS2017 that I mentioned before will be used. If you already had these tasks configured, yet the build continued to use the older version, please let me know so this can be investigated." At least in our case the version would only update once I included the NuGet package per Option C. It appears to me that based on your explanation of how/when Microsoft updates the Hosted VS2017 build agent that will be when it will be up to par. It's OK that we have to include the NuGet package and had to modify the project files directly, it just felt "hackish" when I did it. But the fact it solved the problem and you have explained it in more detail, it has now put a smile on my face. You guys are great! And keep up the great work! If you need my help, go ahead and contact me offline.

dnlnln

My pleasure! Very glad to be of assistance. Please let me know if there's anything else I can help with.

Also may I confirm just one further point: when you sent the build log earlier, was that from a build configuration that included the additional Option A steps? If not, would you mind sending that on that failed build log also?

Many thanks

rbigbie

Hi Daniel,

Yes, in my support ticket the attached failed - because of version issue - VSTS build logs (which had no NuGet in it) had those two tasks in them from Option A and they executed without error. Hope that helps. Thanks.

dnlnln

Great, thanks for that. I've passed this info onto the team for further investigation.