Avoiding the OrleansAdoNetContent folder

[palpha]

The solution to #4243 causes repositories and projects to be polluted by the OrleansAdoNetContent folder. One has to employ various hacks to ensure that the folder is removed after package restore, and in the case of dotnet restore there doesn't even seem to exist any target to use with AfterTargets to get rid of the files.

I see how the files could be useful for someone just starting out with Orleans, but not for an established project. In my case, the files are possibly harmful, as I'm running on a modified schema and these files would only confuse my colleagues.

A possible solution would be to move the copying of these files into the OrleansSQLUtils project. One can then reference the individual packages to bypass the copying of the SQL files.

Has anyone else spent way too much time fighting these files? :) Any other ideas as to what can be done about it?

[sergeybykov]

If these files are causing troubles, I don't see a problem with moving them somewhere else. OrleansSQLUtils though is only a meta-package with zero of its own content. So I'm not sure we want to pollute it.

I wonder what @veikkoeeva thinks.

[palpha]

It's precisely because it is a meta package that I think it's a good place for the copying of these files -- using the meta project is a convenience, an advanced user can use the individual projects instead.

Another possible solution could be to check some variable that can be set if one wants to skip the copying.

[veikkoeeva]

I agree this is annoying. Less of a trouble though that people are storing the files in gists or copying from the GH since they aren't easily found anymore (since the Nuget directory isn't easily found). The previous solution was mor or less a solution to this particular problem. As alluded by @palpha .

I don't have an opinion on other solutions other than keeping the files easily found. That being written, a suggestion solving:

1. Easily to be find place.
2. Doesn't interfere with development.

And we have a good point for refactoring.

I think a good solution would be just to lay them into one place in some "well known place", but what could it be? I think it's near mandatory to allow modified scripts in larger scale deployments due to deployment differences (physical, data quantity, GDPR, whatnot) so fixing it inside assembly or some other metadata would be a very opinionated move.

I have a (personal) feeling it'd be just plain easier if there were only one script even if it would create a few more tables in the DB in some cases (user doesn't use all the features). It's less of a trouble for maintenace and testing too (albeit the changes have been implemented already). I feels it should be less work to deploy the DB using whatever solution one wants to use (my current is just files copied to .sqlproj and using post deployment to deploy them to appropriate schemas and file groups, and yes, te extra files do annoy a bit). Then have a meta package that contains core ADO.NET logic and refer this one script. As it stands, the current solution is set up differently (namespace pragmas and all, a tad annoying from a dev perspective :)).

Do you have change proposal, @palpha ? In short, it would be nice to solve this somehow. :)

[palpha]

My humble opinion is that the OrleansSQLUtils meta project would be a good place. I'm not a NuGet expert, but isn't contentFiles a thing? If the files are packaged as content, they can be excluded when consuming the package (at least with Paket). In any case, bypassing the meta package will bypass the files.

As for the separation of the scripts, I don't mind and it's kind of helpful when shadowing changes in my modified scripts (eg https://github.com/palpha/orleans/blob/postgres-with-schema/src/AdoNet/Orleans.Clustering.AdoNet/PostgreSQLWithSchema-Clustering.sql) that it's in smaller chunks.

[veikkoeeva]

@palpha So the idea would be:

1. Put the separate scripts to the meta-package as opposed to the individual packages. This would add logic to the "advance user case" you noted that they'd like to have the individual packages. As in this case file existence would need to be checked. In fact, it should be checked already now so that modified files aren't overriden (albeit they can show in multiple projects).
2. Make the scripts accessible within the project structure but do not show in Visual Studio.

Partially the Nuget is like it is now since that one I got to work reliably. There's plenty of quirks in the new .csproj format, even between versions, and the old file format when it come to distribute content files, native libraries and so forth. I would personally like to have the scripts accessible in within the project structure in some well-known place and not show up in the VS unless I explicitly add them. I'm not sure about the benefit of adding the files into a meta-packages, especially if they're all in there (as they've been split).

[veikkoeeva]

Discussion and options to solve also at #5168, specifically at #5168 (comment) .

[sergeybykov]

We removed metapackages including Microsoft.Orleans.OrleansSqlUtils in #5946.

What if we simply add a .md file with links to the scripts on GitHub?

[palpha]

Perhaps give the scripts their very own NuGet package, referenced from the online documentation and some strategically chosen intellisense comment? I very much doubt that anyone would attempt to set up Orleans without consulting the documentation, and if the scripts are in a NuGet package that is versioned together with the ADO.NET bits there should be no issues with getting the wrong schema for the version of Orleans in use.

I dislike the idea of putting non-functional files in people's projects. However, if my opinion about this does not represent a large part of the user base, I have no problems working around the issue -- I can delete an .md file automatically just like I delete the scripts :).

[sergeybykov]

I like the idea of a separate NuGet package.

[veikkoeeva]

I think the important thing is just to give notice the scripts are to be found easily enough. I have been looking issues like NuGet/Home#4856, dotnet/project-system#3302 etc. I haven't got far enough to see if those would be helpful or if the files could be moved, say, closer to .sln root or what could work. Maybe important to note there may be options here.

<edit: @palpha You are right there, something should be done. Maybe I'm in minority to research options more throughout before taking action. Albeit slowly it seems since this doesn't come up so often. Maybe due to existence of this issue that people find...