Why does the OrleansAdoNetContent directory appear in every silohost project?

[HermesNew]

Why is there an OrleansAdoNetContent directory in every silohost project? I have a lot of silohost projects, which will interfere with our source management, and this directory is duplicated. It is recommended to have this SQL file only in the nuget package.

[HermesNew]

Previously putting this SQL script into the nuget package was very good. I don't know why it is placed in every silohost project now?

[veikkoeeva]

@HermesNew The reason is that they become more difficult to find after Nuget changed how it caches the code and a little also that they are split into separate scripts now and could not be placed in a common, shared package (the code internally uses ifdefs). There were a lot of questions where to find them and people basically sharing advice with each other to grab the latest from GH, which doesn't always work since the version is master may have changes relative to the code using them.

The issue is at https://github.com/dotnet/orleans/issues/3864, PR at https://github.com/dotnet/orleans/pull/4243. Maybe there is a better way, such as arranging a common directory (and not overwriting it once changes are in)?

[HermesNew]

@veikkoeeva This SQL script only needs to be used once and can be placed in the document. There is absolutely no need to put it in the silohost project. This is currently unreasonable.

[veikkoeeva]

@HermesNew What do you mean by being placed in the document? Which Nuget package specifically you refer with silohost project?

One can alter the script in one's project, it's preferable in depending on physical deployment characteristics, security (which schemas, what rights etc.), maybe GDPR etc. that Orleans framework cannot know. In that sense one needs a copy the scripts so that they aren't overwritten once modified.

The scripts are in multiple Nuget packages, depending which one you choose, you get a slice of the overall deployment. The reasoning was that if one doesn't use some part, it shouldn't appear in the database. This means there isn't just one script one can put in one particular Nuget package, there are many, one in respective packages. This in turn means that when the silo, grain or client project refers to a Nuget package, it gets the scripts. Otherwise one would have to go to look one at place like C:\Users\<username>\.nuget\packages\microsoft.orleans.*.adonet\2.0.0-beta3\lib\netstandard2.0. There certainly are other ways to make this happen. Can you suggest something that makes the scripts visible in the project, preserves the aforementioned qualities related to actual deployment and solves this problem you refer to?

[HermesNew]

@veikkoeeva My proposal is simple. Remove the SQL script directory and provide a download url in the Orleans documentation.

[veikkoeeva]

A solution, at least temporarily, in your particular case could be to add the directory to .gitignore (and maybe hide them from solution explorer).

To your suggestion, the solution could also be to document the scripts will be found in the Nuget directory and remove the need to keep the documentation up-to-date with the download URL and the versions. Also network connection wouldn't be needed as long as the Nuget package is on the disk.

I wonder if there were other options. The discoverability of the scripts in documentation isn't as good as it is currently, albeit having the scripts "on the face" is annoying. It's also a real problem to answer to the same question multiple times in a short span of time (also, there are other things that ought be documented about DB design that should be done besides just running the scripts, such as security).

As of myself, I have wrapped the script to dacpack in a separate soluton, but I it's a bit of annoyance to have the "originals" in the solution, I agree there.