Including SQL Scripts

Feb 28, 2011 at 3:47 PM

Hi there,

I'm currently working on packaging ELMAH 1.2 for NuGet. I think I've got to the point where I've got a really nice initial experience for end users for a lot of scenarios, but would like some advice/guidance/viewpoints on how to handle SQL scripts.
So I've created a core ELMAH package that does most of the transforms and includes the core Elmah.dll, and I've got things like ELMAH.SqlCompact with dependencies on SqlCompact 4.0 etc and that works nicely.
However, I'm now considering the SQL Server/Oracle/MySql etc experience... each of these log implementations requires that scripts be run against the database, and correct configuration of the connectionString.

I can add text to the <description> element of the .nuspec, but somehow I expect it will suffer from the "accept license agreement" syndrome whereby people simply ignore it!!
Maybe something clever could be achieved with PowerShell (though not so easily achieved as I'm a newbie there), but that would fallover on deployment to test/production as the script would need running again.

I was wondering if anyone else has thought about this issue and come up with a "solution".

I certainly need to find somewhere to store the .sql scripts, and ideally give the user instructions to follow.
Perhaps adding functionality to NuGet such that we can include a readme.txt that automatically gets displayed after successful installation??

Any feedback would be gratefully appreciated!

Many thanks,

James

Coordinator
Feb 28, 2011 at 5:08 PM

Hi James,

I think the default experience of ELMAH running on EFCodeFirst.SQLServerCompact is a great experience! I’m glad you did this because I was going to do it myself, but now I don’t have to. Our previous default experience sucked because once you restarted the web server, bye bye log entries! ;)

Are you making the SqlServer, Oracle, MySql versions as separate packages that depend on the main Elmah package? One idea you could consider is writing a PS script for each one that adds a new command to the console. Then people could run the command to configure and run the SQL scripts for those other packages.

We talked about the idea of a readme.txt being automatically displayed but decided against it because if you have a chain of package dependencies, each with a readme.txt, that’ll open a lot of new tabs in VS.

For now, perhaps what you can do is simply add a Elmah_Readme.txt to the “Content” directory of your package. That’ll show up in the root. When I install packages and don’t know what to do next, I often look to see if the package added any files to my project and look there first.

Feb 28, 2011 at 6:15 PM

Hi Phil,

Thanks for the quick response (as always)! Firstly a couple of clarifications about what I'm doing:

1) For now I have the default ELMAH (i.e. core) to continue to be memory based - I think this probably makes sense due to the complexities of later moving to ELMAH.SqlServer... the <errorLog> entry will (AFAIK) get duplicated, which is not something that ELMAH currently supports.

2) The ELMAH.SqlCompact package doesn't use EFCodeFirst.SQLServerCompact - instead it uses the Sql Compact provider that is about to be release in ELMAH 1.2 (currently in Beta right now).

Going back to your suggestions:

1) I don't think I'm ready to embark on the PS script just yet... I think I'll wait and see how the platform evolves and the solutions that others come up with for their packages! :O)

2) I understand about not automatically showing the readme.txt files - perhaps an alternative suggestion would be one such that package authors could have a flag such as <requiresUserConfiguration>true</requiresUserConfiguration>. The package manager could then check this for all packages installed and display an appropriate message at that point e.g. One or more of the packages that you have installed requires further configuration. Please look for readme*.txt or look in your web.config/app.config for further instructions. This could also be for filtering packages so that unexperienced developers could avoid anything that involves extra work!

3) I like the idea of a readme.txt in the "Content" directory... however, I think readme_ELMAH.txt might be a better name as that convention would group all readme*.txt files together, rather than being fragmented across the root folder - maybe that's some guidance that the team should share on the official site??!

Many thanks,


James


Coordinator
Feb 28, 2011 at 6:34 PM

Hi James,

For the Elmah.SqlServerCompact package, I won’t need to do any configuration, right? It’ll just work? That would be ideas.

#2: I like the idea. Log a bug for it if you don’t mind.

#3: Yes, even better!


Phil

From: james_2js [email removed]
Sent: Monday, February 28, 2011 10:15 AM
To: Phil Haack
Subject: Re: Including SQL Scripts [nuget:247882]

From: james_2js

Hi Phil,

Thanks for the quick response (as always)! Firstly a couple of clarifications about what I'm doing:

1) For now I have the default ELMAH (i.e. core) to continue to be memory based - I think this probably makes sense due to the complexities of later moving to ELMAH.SqlServer... the <errorLog> entry will (AFAIK) get duplicated, which is not something that ELMAH currently supports.

2) The ELMAH.SqlCompact package doesn't use EFCodeFirst.SQLServerCompact - instead it uses the Sql Compact provider that is about to be release in ELMAH 1.2 (currently in Beta right now).

Going back to your suggestions:

1) I don't think I'm ready to embark on the PS script just yet... I think I'll wait and see how the platform evolves and the solutions that others come up with for their packages! :O)

2) I understand about not automatically showing the readme.txt files - perhaps an alternative suggestion would be one such that package authors could have a flag such as <requiresUserConfiguration>true</requiresUserConfiguration>. The package manager could then check this for all packages installed and display an appropriate message at that point e.g. One or more of the packages that you have installed requires further configuration. Please look for readme*.txt or look in your web.config/app.config for further instructions. This could also be for filtering packages so that unexperienced developers could avoid anything that involves extra work!

3) I like the idea of a readme.txt in the "Content" directory... however, I think readme_ELMAH.txt might be a better name as that convention would group all readme*.txt files together, rather than being fragmented across the root folder - maybe that's some guidance that the team should share on the official site??!

Many thanks,


James



Feb 28, 2011 at 6:37 PM

3) To be in line with the App_Start convention, It would be best to have an App_ReadMe folder so we don't pollute the root of the app with too many files.

Feb 28, 2011 at 8:03 PM

@Phil:

Yes, ELMAH.SqlCompact will work straight out of the box... as will ELMAH.Access, ELMAH.Xml, ELMAH.SQLite.
ELMAH.SqlServer, ELMAH.Oracle, ELMAH.MySql and ELMAH.PostgreSQL will all require user configuration.

I've raised http://nuget.codeplex.com/workitem/752 as requested.

@David:

I'll start the App_ReadMe convention!
I'm also working on an ELMAH.Mvc3 package... when it's ready, I'll be going with your App_Start convention too!

Cheers,

James 

Feb 28, 2011 at 8:36 PM
james_2js wrote:

I'll start the App_ReadMe convention!
I'm also working on an ELMAH.Mvc3 package... when it's ready, I'll be going with your App_Start convention too!


Great! I'm been contacting all the package owners that use WebActivator ro ask them to use the new convention, so you may as well do it from the start! :)

Mar 2, 2011 at 7:17 PM

@James:

1) For now I have the default ELMAH (i.e. core) to continue to be memory based - I think this probably makes sense due to the complexities of later moving to ELMAH.SqlServer... the <errorLog> entry will (AFAIK) get duplicated, which is not something that ELMAH currently supports.

You could try to get around duplication issues using xdt:Transform="Replace".

Mar 2, 2011 at 10:50 PM

@atif - I've tried the xdt:Transform and unfortunately it doesn't work

@david/@phil - Is this something that you plan to support in NuGet?? I guess this could add complications for a staggered install/uninstall story!

Cheers,

James

Coordinator
Mar 2, 2011 at 11:03 PM

I think there’s already a bug on this. http://nuget.codeplex.com/workitem/711

Its not currently assigned to any release, but is something we’d like to eventually support.

Mar 2, 2011 at 11:14 PM

Thanks Phil... sorry I should've searched the issue tracker before posting!

Cheers,

James