SQL Persistence: Odd Disappearing Scripts

Phil_Sandler · July 20, 2021, 10:12pm

Hello All,

NSB version 7.5
NServiceBus.Persistence.SQL version 6.2
NServiceBus/SqlServer version 6.3.1

We’re seeing an odd problem with scripts being deleted when we run the project without building.

Any time sources change and we build the project, the operational scripts are generated successfully to the bin\Debug\NServiceBus.Persistence.Sql\MsSqlServer directory.

If we run the project without needing to build/rebuild, the scripts disappear immediately, even before any of our startup breakpoints get hit.

This is causing us to get the following error (EnableInstallers() is being used in our startup code):

Expected ‘C:\xxxxx\bin\Debug\NServiceBus.Persistence.Sql\MsSqlServer\Subscription_Create.sql’ to exist. It is possible it was not deployed with the endpoint.

. . . at ScriptLocation.ValidateScriptExists(String createScript) in /_/src/SqlPersistence/ScriptLocation.cs:line 32 . . .

Is this expected behavior? Is there anything we can do to cause the script removal to be skipped?

Let me know if any additional info would be helpful.

Thanks,

Phil

Phil_Sandler · July 26, 2021, 1:24pm

Any thoughts on this? Would repro code help?

DavidBoike · July 26, 2021, 2:19pm

Hey @Phil_Sandler,

Yeah I think we would need a repro to investigate this. I just tried with a .NET Framework 4.8 console app using a non-SDK style project (with packages.config, which is what I am guessing you are using given the lack of a framework in your debug path) and was not able to reproduce the problem.

Phil_Sandler · July 26, 2021, 6:01pm

Thanks David, we’ll work on reproducing in a test project.

Phil

Phil_Sandler · July 27, 2021, 10:20pm

It appears to be related to this MSBuild bug:

github.com/dotnet/msbuild

IncrementalClean deletes transitively-acquired content in Visual Studio

opened 03:30PM - 21 Sep 16 UTC

closed 05:31PM - 09 Jul 21 UTC

rainersigwald

bug changewaves

[This is based on feedback from `connect.microsoft.com`.] If you have: - A proj…ect that copies some files to the output directory (call it `ClassLibraryIndirect`) - A project that depends on `ClassLibraryIndirect` (call it `ClassLibraryDirect`) - A project that depends on `ClassLibraryDirect` (call it `IncrementalClean`) And you build using Visual Studio, some very surprising behavior can occur. Demo projects: https://github.com/rainersigwald/IncrementalCleanDemo On the first (full) build of the main project, the output file is present in ClassLibraryIndirect's bin directory, **and** in IncrementalClean's--as expected. Content files should be transitively passed along. [Selected state](https://github.com/rainersigwald/IncrementalCleanDemo/commit/517e4e8e1a3acc16ec288ca320bf0d34ed039c3e). If you make a change to the main project (to get VS's fast-up-to-date check to cause an actual build) and build just it again, the content file gets deleted from the main project's bin directory. [changes](https://github.com/rainersigwald/IncrementalCleanDemo/commit/e415ad7a74be41e78d910e424c941f5a9acded28) Looking through a diag-level log of the second build, the problem is that the [`IncrementalClean`](https://github.com/Microsoft/msbuild/blob/e7019886b3fd520b547a7353d78d106d72a4b828/src/XMakeTasks/Microsoft.Common.CurrentVersion.targets#L4463-L4520) target [deletes the file](https://github.com/rainersigwald/IncrementalCleanDemo/blob/e415ad7a74be41e78d910e424c941f5a9acded28/build-main-project-in-vs-again.log#L5188), because it incorrectly [thinks it's no longer an output](https://github.com/rainersigwald/IncrementalCleanDemo/commit/e415ad7a74be41e78d910e424c941f5a9acded28#diff-414497d138b9a3671970cce983188d2cL1). This [does **not** happen](https://github.com/rainersigwald/IncrementalCleanDemo/commit/7a9717e0aa9fb07ce1769781cf98d866bd5ae290) when building from the command line using no special properties. But it [**does** happen](https://github.com/rainersigwald/IncrementalCleanDemo/commit/5a3eba2d01f91a16a4463209fed638def3b6d566) when building from the command line setting the property `BuildProjectReferences=false`, which simulates Visual Studio's mechanism of building individual projects. Whether or not a project is built in isolation should not affect the outputs it produces.

So . . . unrelated to NSB. Thanks for your help!