OK, this is pretty much done. nuget packages, both binary and symbol, are now automatically built with all .NET versions inside, ready to be published. Francisco, I disabled this feature until you review it and merge it.

Symbol nuget packages are for publishing PDBs and source code; if they're published correctly Visual Studio (and other IDEs?) know how to automatically find them and download them if necessary: http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package

There is a small problem with the .NET 4.0 build only - it includes mscorlib.dll in the bin for some reason. I'll look into this in the coming days, this is a blocker for using the auto-built nuget packages.

Here's a cool screenshot:

I think it is excellent, Shay! Nice work!
Having the nuget packages automatically built will help get Npgsql fresh releases as fast as possible into Nuget users' hands. :)

About the project license, Npgsql license is in fact the same as the postgresql server: http://opensource.org/licenses/postgresql
Jason Sznol was the guy who created the nuget package and gave the ownership to me. The owner clause is about the nuget package itself or is it about the project? If the second, we would need to change it.

I'm pretty sure that owners and authors relate to the project, not the package... Let me know what you want in these two fields. I'll also replace the license.

Actually Francisco, I think that the license URL you gave is only a template for the Postgres license, i.e. we need to copy it and replace the variables.

We can put the license on the github wiki and give that URL, what do you think?

Oops, sorry. We have a Npgsql project license in this url: http://npgsql.projects.pgfoundry.org/license.html

But I also think we could add a wiki page on github with a lot of information already found in the npgsql.org page. I think the idea could be in the future to have npgsql.org mapped to a github frontpage and wiki pages. What do you think? It would be much easier to update. Today I have to edit the html manually through an ssh connection. By using the wiki pages, it would be much easier to update them.

I absolutely agree, especially if you have to do updates via SSH and HTML :)

You can create a wiki page for the license, tell me when that's done and I'll integrate its URL in our nuspec. Then at some point maybe a redirect from the pgfoundry URL to github?

Note: Right now the Npgsql version is hard-coded into the nuspec file. This means it must be updated in two different places (the nuspec and the AssemblyVersion.cs). Not so good, but I guess it'll be OK for now. I'll try to think of a good solution.

As the ownership is about the npgsql project itself, please update it with my name and Josh Cooley's.

Please, also, add your name and Glen Parker to the list of authors. You two have made significant contributions to Npgsql project!

You can create a wiki page for the license, tell me when that's done and I'll integrate its URL in our nuspec. Then at some point maybe a redirect from the pgfoundry URL to github?

Done: https://github.com/npgsql/Npgsql/wiki/License

OK Francisco, the nuspec is updated. I've also changed the project URL to point to the github page.

Please take a final look and let me know if it's OK with you.

Thanks, Shay!
I think it is ready to go!

Great, you can go ahead and merge!

In the meantime I also managed to resolve the mscorlib.dll problem on .NET 4.0, it seems .NET 4.0 wasn't installed properly on the build server. All good now, so the nuget packages should really be ready to go.

Francisco, I suggest that before actually releasing the 2.1.0 nuget you try it out a little, just to make sure it's OK. Also, do you already have an account at SymbolSource.org (like discussed here: http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package)?

Great, you can go ahead and merge!

In the meantime I also managed to resolve the mscorlib.dll problem on .NET 4.0, it seems .NET 4.0 wasn't installed properly on the build server. All good now, so the nuget packages should really be ready to go.

Excellent!

Francisco, I suggest that before actually releasing the 2.1.0 nuget you try it out a little, just to make sure it's OK. Also, do you already have an account at SymbolSource.org (like discussed here: http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package)?

Ok. I'll try it out.

I didn't have an account yet, but I'll create one.

Just a last change: please, add you name to the owners section of the nuspec.

I'm not so sure I deserve this really... but if you insist... :)

Changed and rebased

I'm not so sure I deserve this really... but if you insist... :)

:)

You made a lot of contributions and is helping me in a lot on the infrastructure to make Npgsql releases easier and codebase changes also more error and regression free with the team city integration.

I'm happy to help :)

One more thing I think we should care of before we release - there is the issue of entity framework 6 vs. pre-6, and also maybe mono. I think we had a discussion some time ago and said that we maybe need a separate nuget for EF6 (I think that makes sense). I also think that for mono nothing special is needed, but I want to check what we said anyway.

Probably not today, it's getting late here in Israel :)

OK, I reenabled the TeamCity build step to do nuget pack, everything seems to be working great. You can log into TeamCity and look under "Artifacts" (or build outputs), and you will see both nugets.

I'm happy to help :)

Thank you very much for your help, Shay! You rock!

One more thing I think we should care of before we release - there is the issue of entity framework 6 vs. pre-6, and also maybe mono. I think we had a discussion some time ago and said that we maybe need a separate nuget for EF6 (I think that makes sense). I also think that for mono nothing special is needed, but I want to check what we said anyway.

I agree with you about the nuget for EF6.
It would be very good if we could create the mono builds without anything special. Please, let me know when you have more info about it.

Probably not today, it's getting late here in Israel :)

Here is starting to get dark. But we are in daylight savings timezone now. :)

OK, I reenabled the TeamCity build step to do nuget pack, everything seems to be working great. You can log into TeamCity and look under "Artifacts" (or build outputs), and you will see both nugets.

I was almost saying that I wasn't able to see the nuget packages until I checked the artifacts of the All build type id. :)

Here it is already almost midnight! Enough hacking for the weekend...

A few thoughts though:

• EF6 is already out and comes with VS2013, so it is the official version now.
• I think it means that the "default" npgsql nuget should be with EF6.
• mono supports only EF6 (because it is the only open-source release).
• EF6 supports only .Net 4.0 and above

Based on the above, it seems we may need three nuget packages:

1. "Default" npgsql package. With EF6, only .NET 4.0 and .NET 4.5. Works on .NET, mono.
2. Legacy EF package. Contains old EF, all .NET versions. Does not work on mono
3. No-EF package, for people who don't need any EF. No EF, all .NET versions, also works on everything.

This may get confusing, but if you want to support everyone I'm not sure there's another way. Maybe it's a good idea to share this question on the devel-list...

Hi.

Sorry for disturbing.
I'd like to express my opinion.

Please consider to supply them in one nuget package.

• .NET 4.0/4.5 Npgsql.dll supports: ADO .net (DbConnection/NpgsqlConnection) + EFv4
• .NET 4.0/4.5 NpgsqlEF6.dll supports: EFv6

I think that EFv4 and EFv6 should be provided separately, because they can coexist each other in one application.

@kenjiuno, you're not disturbing at all, thanks for your opinion. You know about EF much more than me.

I would love to supply the different versions in one nuget package, but there's one problem: when you install a package, nuget automatically adds references in your project to the DLLs provided, according to the .NET version. So which DLL would you get a reference to: Npgsql.dll, or NpgsqlEF6.dll? How is nuget supposed to know?

There's another issue. EF6 requires that our nuget package actually depend on the EF6 nuget package. A user that doesn't want EF6 (i.e. wants to use ADO.NET) shouldn't get the EF6 dependency, but again, if we have one package with both Npgsql.dll and NpgsqlEF6.dll, how would that work?

This leads me to say that we need two packages, clearly labeled, so the user can choose at installation time whether they want EF6 or not... Do you see another way?

Regardless of the above EF6 discussion, mono doesn't supports EFv4 (not open source), which is why we may need an additional package with no entity framework whatsoever (for mono ADO.NET usage). I'll do some research, maybe it's possible to get around this problem.

Let's continue the entity framework discussion here: #110