[npgsql-Bugs][1011294] policy.2.0.Npgsql.dll built against .NET 4.0 in all versions #131

Closed
franciscojunior opened this Issue Dec 17, 2013 · 8 comments

Projects

None yet

2 participants

@franciscojunior
Member

Akos Lukacs (akoslukacs)

Hi!

The policy.2.0.Npgsql.dll file latest download, and the nuget package for .net 3.5 is built against .NET 4.0, therefore it can't be loaded in a .NET 3.5 app.

Is this file required? Actually if I delete this assembly reference, the application runs as far as I can tell.


Date: 2013-12-17 14:00
Sender: Richard Brown

The latest NuGet package (2.0.14.2) still appears to have this problem:

C:>corflags packages\Npgsql.2.0.14.2\lib\net35\policy.2.0.Npgsql.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.

Version : v4.0.30319
CLR Header: 2.5
PE : PE32
CorFlags : 9
ILONLY : 1
32BIT : 0
Signed : 1


Date: 2013-06-28 14:56
Sender: Francisco Figueiredo jr.

This is fixed in github. See this pull request with the patch:
#24

@franciscojunior
Member

Hi @glenebob Glen!

I think we will need to update Nuget package again :)

This time we will just need to replace the policy assembly in the net20 and net35 folders. :)

I'll take a look at this.

@roji
Member
roji commented Dec 21, 2013

I think there's some confusion here...

Since publisher policy files are for GAC only, they shouldn't be included in the nuget (but rather installed with the installer being worked on in #128). Including the publisher policy in the nuget adds an assembly reference to them (should never happen), and since we have a .NET 4.0 publisher policy DLL the guy's project doesn't compile.

Bottom line, I think that if you simply remove the publisher policy file from nuget altogether we're fine.

I plan to spend a bit of time and really understand how the mechanism actually works. FYI, I've just pushed two changes to master which integrate the process of creation of the publisher policy files into the build, rather than an external batch file etc. But it's true that because of this the build produces only .NET 4.0 publisher policy DLLs since it's not clear how to make the AL.EXE tool target other frameworks. To be honest I'm not even sure that's actually a problem.

In any case, it seems pretty important to get a nuget out there without any publisher policy DLLs...

@franciscojunior
Member

Bottom line, I think that if you simply remove the publisher policy file from nuget altogether we're fine.

+1 for this.

Maybe we could provide another nuget package with those publisher files? This way if the developer wants it, she can simply add another nuget reference.

I plan to spend a bit of time and really understand how the mechanism actually works. FYI, I've just pushed two changes to master which integrate the process of creation of the publisher policy files into the build, rather than an external batch file etc. But it's true that because of this the build produces only .NET 4.0 publisher policy DLLs since it's not clear how to make the AL.EXE tool target other frameworks. To be honest I'm not even sure that's actually a problem.

I think the al.exe only produces the target for the framework it came from. That's why the policy build script uses two different al.exe.

The actual problem is when the developer wants to use Npgsql in a old instalation where she can't/doesn't want install .net 4.0. As the publisher file has a reference to .net 4.0, the system can't load it.

@roji
Member
roji commented Dec 21, 2013

@franciscojunior, here's how I understand it (based on http://msdn.microsoft.com/en-us/library/dz32563a(v=vs.110).aspx and other resources)

Developers never add references to publisher policy DLLs in their projects. The only thing you can do with them is stick them inside your GAC. If you do this and run an application compiled against an old version of Npgsql, the publisher policy functions as a redirection to load a newer version instead. It's totally optional, and in fact I don't know of any open source project that provides them in general. You're basically expected to compile against a certain version of Npgsql and then run against that same version. If you want a newer version, recompile against the newer version.

It doesn't mean I'm against publisher policy files :) But that first, it makes no sense to include them in any nuget package (if I understand things correctly). It only makes sense in a GAC installer such as the one @kenjiuno is working on in #128.

I'm not even sure it makes sense to talk about .NET 2.0 and .NET 4.0 with publisher policy DLLs. These are DLLs created directly with AL.EXE (the linker), the don't contain any reference to any framework DLL, and are basically containers for the XML which specifies the version redirects. When I have a bit of time I'll try playing around with it, putting a publisher policy DLL produced with a recent, ".NET 4.0" AL.EXE, into the 2.0 GAC and see if it works. The important point is that nobody ever references these DLLs in any project - they're a redirection for assembly resolution.

And in any case, I think it's fine in general to release Npgsql versions without publisher policy files (like most packages out there).

@franciscojunior
Member

I agree with you that we shouldn't add those policy files on our Npgsql nuget files.

You're basically expected to compile against a certain version of Npgsql and then run against that same version. If you want a newer version, recompile against the newer version.

That's mine and Josh's interpretation too. But I remember in the past we started to receive reports from users who wanted to be able to simply drop in the new Npgsql version in the bin folder of a compiled application and have it working without having to recompile it :)
That's when we started to use those redirection publisher files.

I'm totally fine to remove them and as I said in #132 (comment), if it is really needed, I think one optimal solution would be to have another nuget package just to hold the policy files or maybe document and tell users how to create those binary policy files.

What do you think?

@roji
Member
roji commented Dec 22, 2013

I think that's a good idea, except for one thing... Since PP DLLs are supposed to go in the GAC and not in projects, I don't think they're supposed to be distributed as nugets. nugets can't put things in GACs, and in fact add references in your projects to the DLLs (which should never happen with PP DLLs).

The only good/recommended way to distribute DLLs that need to get in the GAC, as far as I understand, is via a Windows Installer, which also updates reference counting and supports uninstallation properly (this is #128).

So I'd say: forget about publisher policy files for just a little while, until #128 is complete (I think it's pretty close, and I promise to help @kenjiuno out if needed). I'll also make sure to produce .NET 2.0 compatible PP DLLs as well.

@franciscojunior
Member

So I'd say: forget about publisher policy files for just a little while, until #128 is complete (I think it's pretty close, and I promise to help @kenjiuno out if needed). I'll also make sure to produce .NET 2.0 compatible PP DLLs as well.

+1

@roji roji was assigned Dec 29, 2013
@franciscojunior
Member

As we don't use publisher policy files anymore, I'm closing this issue. If we find any problem related to it, we can reopen and continue discussing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment