Assemblies should be strong-name signed about sqlitepcl.raw HOT 41 CLOSED

May I propose an alternate suggestion - people who care about strong naming are almost(*) universally Wrong, but instead of those people suffering for their choices, they've somehow instead Tom Sawyered OSS maintainers and contributors into suffering instead.

You should not fall for such a trap, and instead tell 100% of people interested in strong naming to, as Jerry so eloquently put it:

https://www.youtube.com/watch?v=FFrag8ll85w

from sqlitepcl.raw.

I gave it a go at fixing this myself to send a pull request, but @ericsink as your README rightly states: building this is very difficult. I started changing gen_build.cs to add signing to the build, but as there's no way for me to validate it, and you can probably do this fairly easily yourself, maybe I'll just leave it to you.

@ericsink can you please comment on if and when you can fix this bug?

from sqlitepcl.raw.

My first task to address this issue would be to understand it more than I do now. I can't promise anything yet.

from sqlitepcl.raw.

https://twitter.com/eric_sink/status/623939641687830529

from sqlitepcl.raw.

libgit2sharp stance on this issue:

libgit2/libgit2sharp#212

from sqlitepcl.raw.

And lots of interesting discussion on the matter here:

octokit/octokit.net#405

from sqlitepcl.raw.

And this one too:

http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/

from sqlitepcl.raw.

I haven't read all of it, but I've read and heard some, and been given a summary by an expert in the area. Strong naming forces the app to use binding redirects where it wasn't necessary before. NuGet automatically adds these though, so in practice I've never come across a problem with a strong-name signed nuget package (nor have I heard anyone complain from my strong name sign all of my own).
Your extremely unique build system in this project makes forking it to create my own signed build very difficult. Also, while some folks create signed and unsigned versions of their packages, and that might work well for 'front end' packages where the user can pick which one, it may not work so well for the back end packages such as this one where it is typically brought in by another package such that I can't switch it out.

But an extra package for the signed version is better than nothing, since building a fork is so tricky.

In my world though, the ideal thing is just to always strong-name sign. I don't know of any blocking issues it creates for others, and it certainly unblocks a good % of the crowd.

from sqlitepcl.raw.

I'll continue looking into this, as I haven't finished reading all that stuff either.

But I've seen more than enough to make me want to proceed with caution. I tend to be conservative about potentially breaking changes anyway, and this one looks (from a distance) to be a mess. Some of the smartest developers I know are advising against it. And so far you ( @AArnott ) are the only one who has expressed an interest. I need to be darn sure this change wouldn't screw stuff up.

from sqlitepcl.raw.

The way to handle strong naming is to only increase the assembly version for major releases. JSON.NET has a good write up on the process they are using. They still version NuGet, but they only change the assembly version on major releases.

By the way I could use this feature myself for some shell extensions that I am in the process of creating.

from sqlitepcl.raw.

The way to handle strong naming is to only increase the assembly version for major releases. JSON.NET has a good write up on the process they are using. They still version NuGet, but they only change the assembly version on major releases.

I'm currently getting lots of bug reports from JSON.NET users on Xamarin throwing warnings because of this scheme

from sqlitepcl.raw.

@paulcbetts that's a very limited viewpoint you have there. There are many folks that must strong name sign. And that rules out leveraging the work of any libraries that don't strong name sign. Telling those asking for it that they don't need it doesn't help or change anything.

from sqlitepcl.raw.

Can anyone succinctly state on this thread what the cost or negative consequences would be to this library, its author or its users if this library started strong name signing? I can't think of any practical, significant negatives, but I and many others have a very practical positive: We can start using it.

from sqlitepcl.raw.

BTW, I just did a scan of the top few dozen packages on NuGet.org. Not surprisingly, all of those that carry .NET assemblies are strong-name signed. In fact, I daresay most nuget packages that have significant download numbers will be strong-name signed.
Is that because these packages are so awesome that they managed to become popular in spite of a terrible choice to strong name sign? Or is it more likely that strong-name signing doesn't have such a negative impact after all, despite some of the community's outcry against it?
How likely is an otherwise great library to be popular on nuget.org that doesn't strong-name sign? Evidently it's unlikely to be among the most popular based on the stats on nuget.org (in my limited test anyway). Granted for libraries with very specific audiences that never need to strong-name sign their own projects, you could be popular without signing (for example, Windows Phone-only libraries would be fine since referencing assemblies that are not signed is allowed on Windows Phone). But for libraries of general interest (such as SQLitePCL.raw), virtually all the popular ones do it -- and yes, that helps them be popular because it allows more projects to consume them.

from sqlitepcl.raw.

Can anyone succinctly state on this thread what the cost or negative consequences would be to this library, its author or its users if this library started strong name signing?

Sure, I outlined it here: reactiveui/ReactiveUI#43 (comment) - the money quote:

"Here's the problem with strong naming. Every time a new contributor comes along, they now have to have an extremely demotivating fight with Visual Studio to get the project to build, or to replace the official binaries with ones they've built for testing. Motivation sapped, for literally zero benefit."

This is the reason to not strong name, is that it prevents / inhibits people from building and using their own versions, because it makes it a PITA. Building your own version and seeing your change live is the Gateway Drug to Open Source.

People at Microsoft including the OP don't feel this pain, because the very first thing any DevDiv developer does as part of their onboarding is install an internal-only tool called "HijackStrongNaming", which (as its name implies), works around most of the issues related to SN that Microsoft's customers face during development.

Is that because these packages are so awesome that they managed to become popular in spite of a terrible choice to strong name sign? Or is it more likely that strong-name signing doesn't have such a negative impact after all, despite some of the community's outcry against it?

I crossed off all of the packages in the top list that are authored by Microsoft or have significant MS involvement, and therefore must be SN'd because of Microsoft corporate policy:

I can't think of any practical, significant negatives, but I and many others have a very practical positive: We can start using it.

If you want to use SQLite inside Microsoft, just say so! That's at least a valid reason for strong naming.

from sqlitepcl.raw.

@paulcbetts Yes, I didn't count the Microsoft ones on that list either. I went pretty far down the list as a result of skipping them in order to get a reasonable sample. Still, I found they were all strong-name signed as far down as I went. I also overlooked CoreFX, which I think is probably strong-name signed as well, but CoreCLR doesn't enforce signatures so it's not a compatible problem.

Here's the problem with strong naming. Every time a new contributor comes along, they now have to have an extremely demotivating fight with Visual Studio to get the project to build, or to replace the official binaries with ones they've built for testing. Motivation sapped, for literally zero benefit.

I don't see the problems you're seeing. Are you assuming that the private key used for strong-name signing isn't available in the open source repo? I'm not making that assumption. In fact almost all my open source projects (and others do this too) include an unencrypted private key in the open source project exactly so that anyone can build and replace my assembly with their own. Since strong-name signing is part of the build, this means strong-name signing added 0 cost to anyone who wants to consume or rebuild my library.

People at Microsoft including the OP don't feel this pain, because the very first thing any DevDiv developer does as part of their onboarding is install an internal-only tool called "HijackStrongNaming", which (as its name implies), works around most of the issues related to SN that Microsoft's customers face during development.

What is "the OP"? And not everyone at Microsoft works in DevDiv either. Yes, I run StrongNameHijack, but that doesn't eliminate any of the pains of strong-name signing other than that I can now build locally and run my stuff even though MS won't give me the private key. Sure, that's an extremely important point, but as I point out above, open source projects don't need to hide their private key, so it's even better in the open source world of strong-name signing than within MS internally. I do plenty of open source and all my libraries are strong-named (all but one with a publicly disclosed "private" key). And I've never had a single complaint about it, but I've had others fork and contribute all the same.

If you want to use SQLite inside Microsoft, just say so! That's at least a valid reason for strong naming.

Yes, I'm working on a Visual Studio feature that for now depends on SQLite. I've temporarily disabled strong-name signing of my library in order to make progress in using this library but I can't ship that way. Either this library gets strong-name signed, or I'll have to stop using this library in the Visual Studio feature.
The reason I didn't bring it up before now is because I think the arguments in favor of strong-name signing stand on their own, without bringing a potentially interesting potential customer into the mix.

from sqlitepcl.raw.

FWIW, I want to offer my response to this question from @AArnott :

"Can anyone succinctly state on this thread what the cost or negative consequences would be to this library, its author or its users if this library started strong name signing?"

Like I've said, I don't know a heckuva lot about strong naming. But my experience tells me that there is roughly zero chance that implementing what you want is as simple as you say.

SQLitePCL.raw builds and includes dozens of different configurations. It supports several platforms, both desktop-ish and mobile. It involves native code, and for some platforms it ships a pre-built version of that native code, compiled multiple times in different ways. It supports two different ways of getting from C# down to that native code. It has to work with Visual Studio and Xamarin Studio. It uses MSBuild trickery. It pushes the functionality of nuget in extreme ways.

If there is ANY other nuget package which is trying to deal with this much config complexity, I am unaware of it.

And [basically] every one of those configurations supports a valid use case.

You have suggested yet another valid use case. And I do care about it.

But if you're trying to tell me this is going to be simple and will involve no tradeoffs, I'm sorry, that kind of claim has no credibility here. :-) Nothing with SQLitePCL.raw is ever simple. That's why it exists.

So I am going to work on this issue, but I cannot make any promises about how it turns out. My first steps are to see if it's possible to treat "bool strongnamed" as yet another axis of configuration, simply because that path reduces the risks of screwing up anything I've already got.

We'll see.

from sqlitepcl.raw.

So @paulcbetts says:

"Here's the problem with strong naming. Every time a new contributor comes along, they now have to have an extremely demotivating fight with Visual Studio to get the project to build..."

I observe that this particular argument against strong naming does not apply to this particular project. SQLitePCL.raw doesn't care about attracting contributors, and is very nearly hostile to same, since it is so hard to build.

Furthermore, referencing what @AArnott said at the top of this thread, the difficulty in building this project gives me very little moral high ground if I want to use the same answer @paulcbetts uses (roughly: "if you want this library to be strong named, then build it yourself").

Still figuring this out...

from sqlitepcl.raw.

@paulcbetts

People at Microsoft including the OP don't feel this pain, because the very first thing any DevDiv developer does as part of their onboarding is install an internal-only tool called "HijackStrongNaming", which (as its name implies), works around most of the issues related to SN that Microsoft's customers face during development.

This was definitely true in the past but it is changing (slowly). Roslyn for instance does not use this tool and we have fought vigorously any attempt to push it into our tool chain. We do our best to developer our code exactly like our customers do including feeling all of the pain of strong naming our assemblies.

from sqlitepcl.raw.

We do our best to developer our code exactly like our customers do including feeling all of the pain of strong naming our assemblies.

You're doin' the Lord's work @jaredpar :)

from sqlitepcl.raw.

👍🏻

On Jul 28, 2015, at 9:02 AM, Paul Betts [email protected] wrote:

We do our best to developer our code exactly like our customers do including feeling all of the pain of strong naming our assemblies.

You're doin' the Lord's work @jaredpar

—
Reply to this email directly or view it on GitHub.

from sqlitepcl.raw.

Thanks, @ericsink. Let me know if you run into issues that I can help with. I know MSBuild somewhat, but I certainly don't know your gen_build.cs very well.

from sqlitepcl.raw.

@AArnott csc gen_build.cs is all that you have to run to create the exe that generates all the structures needed.

@ericsink I honestly don't know if you need to change anything. Granted your process is hard to build, and down right hostile to contributors. However, I did need a strong name for integration with COM components (don't ask...) Long story short, I generated my own build and took the solution I needed and strong named it. It took all of about 30 minutes.

You also really only have one major integration projects that uses you, beside your own Ugly project. And that project is SQLite-Net, and their delivery system of the raw CS file is also hostile. But I just took their CS file, added #define USE_SQLITEPCL_RAW with my strong name build and I was off to the races. It took me all of about 30 minutes.

I honestly don't think you need to change anything, because it is going to make your life harder than it is managing a large todo.txt list. I am with @paulcbetts.

from sqlitepcl.raw.

Yes, I've figured that out. What was trickier was modifying gen_build.cs to strong name sign in the generated projects.

from sqlitepcl.raw.

You also really only have one major integration projects that uses you, beside your own Ugly project

Fwiw, Akavache also uses SQLitePCL.raw, via a forked SQLite-Net

from sqlitepcl.raw.

FWIW, Frank Krueger ships a nuget packaged version of SQLite-net with SQLitePCL.raw underneath it:

https://www.nuget.org/packages/sqlite-net-pcl/

And based on questions I get from folks at Xamarin University, it appears that they are using the above version of SQLite-net in their training now.

And like Paul said, there is Akavache.

And Couchbase Lite.

And SQLitePCL.pretty. Not sure how many users it has, but its author has contributed a number of helpful pull requests to SQLitePCL.raw.

And my company (Zumero) uses SQLitePCL.raw in several contexts.

Bottom line: This project is not super-popular but it has enough users that I try to take great care before doing anything that would cause them additional hassle or regression.

from sqlitepcl.raw.

You are right. But you really proved my point also. Much of above mentioned projects are derivatives of SQLite-net. Either you have a direct build of the source file (SQLite-PCL-net) I mentioned or you have an indirect build of the source file. (Acavanche)

To make my point I convienently forgot about SQLitePCL.pretty, sorry @bordoley, I know him IRL.

There is this huge philosophical debate going on about the merits of strong naming. But, the point is you don't need to strong name. You don't have millions of integration points like JSON.Net, that cause weird conflicts between NuGet packages. You have one major intigration that also doesn't strong name. (SQLite-Plc-net directly and Acavanche indirectly) And a few minor ones.

If the handful of people who need strong naming need it, it is very simple to compile a strong name version them self. I would hold off on doing this work, because there really isn't a compelling reason to sign the assembly.

from sqlitepcl.raw.

@nberardi: FWIW no way am I'm bothering to strong name SQLitePCL.pretty...

from sqlitepcl.raw.

I observe that this particular argument against strong naming does not apply to this particular project.
SQLitePCL.raw doesn't care about attracting contributors, and is very nearly hostile to same, since it is > so hard to build.

@ericsink: I do think there are some changes that could be made to this project to make it more approachable (code organization, refactoring, consistent code style, etc.) but its a fair point to state that its not a priority.

from sqlitepcl.raw.

"I do think there are some changes that could be made to this project to make it more approachable"

I'll have to plead guilty on that charge. :-)

from sqlitepcl.raw.

I fail to see any reason to not strong name in this thread yet. It wouldn't seem to cause any problem for the downstream consuming packages if this project started strong name signing.

@nberardi said:

it is very simple to compile a strong name version them self. I would hold off on doing this work, because there really isn't a compelling reason to sign the assembly.

No, it's not simple to compile a strong-name version of this. The readme of this project itself says it's practically impossible to build it at all. And yes, there is a compelling reason to sign this assembly: as I've said repeatedly, it allows more consumers to use your open source project.

You have nothing to lose, and more folks consuming you to gain, by strong name signing.

from sqlitepcl.raw.

The readme is a little over dramatic. It's only that hard if you're trying to build a release build for all target platforms. Building a .net45 assembly for use in visual studio should be rather easy. I've done similar builds in the past for running tests on PRs I've submitted.

from sqlitepcl.raw.

Are there any additional complexities with using strong naming for libraries that use the pcl bait and switch trick? Like this one?

from sqlitepcl.raw.

@bordoley, none that I can think of. I use the bait and switch trick in pclcrypto, which is strong name signed. I don't recall having any problems attributable to that.

from sqlitepcl.raw.

For pclcrypto, do you sign the bait and all the platform assemblies with the same SNK?

Do you use the James NK trick and never update AssemblyVersion?

from sqlitepcl.raw.

Yes, you must make the reference and platform assemblies look the same as far as assembly name goes, including the public key token.
I'm not familiar with the James NK trick. But I definitely update the assembly version. I think with each release. I know the corefx folks are keen on changing the assembly version for every single release. I'm not sure all the reasons. I think I change the assembly version for every release of pclcrypto (except perhaps the patch version increments), but I don't recall right now.

from sqlitepcl.raw.

Thought I'd chime in for another alternative to this. There seems to be a nuget package that allows signing other nuget packages after the fact -> https://www.nuget.org/packages/Nivot.StrongNaming/

I am also curious about this. I know signed packages cannot consume unsigned ones, but is the reverse true? (i.e. can unsigned packages consume signed ones).

from sqlitepcl.raw.

I am also curious about this. I know signed packages cannot consume unsigned ones, but is the reverse true? (i.e. can unsigned packages consume signed ones).

Yes unsigned packages can consume signed ones. If they couldn't, you wouldn't be able to compile unsigned code against all the .NET BCL libraries. Like mscorlib. System. Etc.

Nick Berardi
(484) 302-0125
Sent on the go from my phone.

On Aug 26, 2015, at 4:30 PM, Jim Borden [email protected] wrote:

Thought I'd chime in for another alternative to this. There seems to be a nuget package that allows signing other nuget packages after the fact -> https://www.nuget.org/packages/Nivot.StrongNaming/

I am also curious about this. I know signed packages cannot consume unsigned ones, but is the reverse true? (i.e. can unsigned packages consume signed ones).

—
Reply to this email directly or view it on GitHub.

from sqlitepcl.raw.

@ericsink, We have recently updated https://github.com/Azure/azure-mobile-apps-net-client to take dependency on SQLitePCL.bundle_green 0.9.3. We are running into the same issue:
Could not load file or assembly 'SQLitePCL.raw, Version=0.9.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required
as azure-mobile-apps nuget packages are built using signed assemblies. Are there any plans to sign this assembly?

from sqlitepcl.raw.

I will take another look at this issue and try to get it resolved. I have been hesitant in the past because I am concerned about causing undesirable side effects for some, and I lack experience with strong naming to be confident. But it looks like we've got another reason to push through those concerns and make it happen.

from sqlitepcl.raw.

The 1.0 release contains signed assemblies.

from sqlitepcl.raw.