Prevent language resource dlls from being output

[ensign-nemo]

Since switching to Microsoft.Data.SqlClient, we now get folders output for the following language codes:

de, es, fr, it, ja, ko, pt-BR, ru, zh-Hans, zh-Hant

Each folder contains a 250kb Microsoft.Data.SqlClient.resources.dll file, totalling 2.5Mb in all.

We don't have any need for these regionalisation/internationalisation resources, and yet they are generated every time. Presumably this list will grow over time as new languages are ported.

How do we prevent these folders from being generated and becoming part of the build product?

[ErikEJ]

Add a post build event with something like:

RD /S /Q "$(TargetDir)de"
RD /S /Q "$(TargetDir)es"
RD /S /Q "$(TargetDir)ja"
RD /S /Q "$(TargetDir)ko"

[ensign-nemo]

Add a post build event with something like:

RD /S /Q "$(TargetDir)de"
RD /S /Q "$(TargetDir)es"
RD /S /Q "$(TargetDir)ja"
RD /S /Q "$(TargetDir)ko"

That will doubtless achieve the same result, but would need maintained as new language packs get added. Is there nothing systematic that switches this behaviour off?

[JRahnama]

Hi @ensign-nemo. looking into this issue may help us to have a better understanding. I will look into it and I suggest you do too to see if there is anything to be done from your side.

[JRahnama]

@ensign-nemo I looked into satellite packages. Currently we are supporting nine or ten different languages, hence using satellite packages for us requires maintaining (release wise) 10 different nuget packages at each release. Since localization at the moment is only provided for .NETFramework it does not look like a good approach for us at this time. We can get back to this, if it gets more request from community, when localization is available in .Net/.NetCore. For now as @ErikEJ mentioned the best way for you is deleting those folders. I can also call for @David-Engel's opinion on this matter.

[JRahnama]

for those who wants to follow, link to the MS doc and satellite assemblies for .NET. Link to one of MS libraris that uses that pattern Microsoft.AspNet.mvc as the primary language and German language at Microsoft.AspNet.Mvc.de. Once again this could be prioritize if it gets more interest from community.

[David-Engel]

That will doubtless achieve the same result, but would need maintained as new language packs get added.

That's a pretty rare event.

Implementing satellite packages for languages would add complexity. It also would greatly multiply the number of packages if we want to implement things like #1108. I don't see this being a big enough issue to be worth the effort over something like #1108.

[JRahnama]

I am closing the issue as this will never going to happen due to complexity and conflict with other solutions/plans we have for future.

[SimonCropp]

the annoying thing for me is that most of these resource files are used to localize exception messages, which just result in making exceptions more difficult to google-bing for. So i get the tax of extra files to ignore/cleanup for a net-negative value

[JJoe2]

@SimonCropp - I agree. If this were an open source project run by one or two volunteers I could understand responses like:
"Once again this could be prioritize if it gets more interest from community"
"Implementing satellite packages for languages would add complexity"

But the project purports to be "the flagship SQL Server driver going forward" and I think it should have a best practice solution for localization.

[SimonCropp]

@JJoe2

If this were an open source project run by one or two volunteers I could understand responses like: "Once again this could be prioritize if it gets more interest from community"

but that was a response from a dev from MS who maintains "the flagship SQL Server driver going forward"

But the project purports to be "the flagship SQL Server driver going forward" and I think it should have a best practice solution for localization.

"best practice" should be able to evolve over time when it become clear there is a "better practice"

[JRahnama]

@SimonCropp, thanks for updating this thread, the fact that you do not need localization does not mean that they should not be there there are so many other users all over the world using the driver. One can easily delete those folders. The cons of having Satellite packages are more than its benefits in our case and it is in contradiction with our future goals with the driver as it was mentioned by @David-Engel . Regarding "best practice" topic, what are the facts and reasoning that put satellite package in "best practice" category for SqlClient driver?

[dsplaisted]

I believe that the SatelliteResourceLanguages property may be what you're looking for. It allows for an app to filter the language resources that will be included, even if referenced NuGet packages may include more.

[ensign-nemo]

I believe that the SatelliteResourceLanguages property may be what you're looking for. It allows for an app to filter the language resources that will be included, even if referenced NuGet packages may include more.

Genius - worked for me. Many thanks indeed.

[ErikEJ]

@dsplaisted great tip, generally very useful

[JRahnama]

@dsplaisted thank you.

[MrKelpy]

For those that can't for some reason use the SatelliteResourceLanguages solution as mentioned by @dsplaisted, adding the following after build command to your project's .csproj file will also work:

<Target Name="AfterBuild">
    <ItemGroup>
        <ResourceFiles Include="$(OutputPath)\**\Microsoft.Data.SqlClient.resources.dll"/>
    </ItemGroup>
    <RemoveDir Directories="@(ResourceFiles->'%(RootDir)%(Directory)')" />
</Target>

This will delete every directory containing a Microsoft.Data.SqlClient.resources.dll file within it. These perfectly match the clutter .dll files, and so it'll clean stuff up, with no maintenance needed.