DirectoryNotFoundException after installing ELMAH.Access NuGet package with no App_Data

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Checkout branch RB-1.2-NuGet
2. Run pack.cmd in the root of the working directory.
3. Launch VS 2010.
4. Select File, then New, then Project, then ASP.NET Web Application (C#).
5. Select the web application project node in the Solution Explorer, then Add 
Library Reference Package.
6. Select Settings.
7. In Available package sources list, add one named ELMAH where Source points 
to the local directory where the packages are located. Click OK.
8. Again, select the web application project node in the Solution Explorer, 
then Add Library Reference Package.
9. In the Add Library Reference Package, select Online on the left and then 
ELMAH.
10. Select the ELMAH.Access package and click Install.
11. Delete the App_Data directory to simulate a web site/app with no App_Data 
directory.
12. Press F5.
13. When the browser finshes launching the home page, go to the address bar and 
type in the URL to the error log page, e.g. http://www.example.com/elmah.axd

What is the expected output? What do you see instead?

Expected to see the error log page. Instead, a DirectoryNotFoundException 
occurs saying “Could not find part of the path.” This occurs because the 
connection string assumes that the web app/site will always have an App_Data 
directory already there but this may not always be the case. The package should 
be prepared to handle the case.

Additional information:

OS: Windows 7 Ultimate
ASP.NET: v4.0
Visual Studio: 2010 SP1
Web Server: ASP.NET Development Server
Revision: r803

Original issue reported on code.google.com by azizatif on 11 Mar 2011 at 8:31

[GoogleCodeExporter]

Not sure if this is a NuGet issue... i.e. should NuGet create the App_Data 
folder (which in itself) currently poses issues (see 
http://nuget.codeplex.com/workitem/810)

or

Should AccessErrorLog try and create the missing folder itself??

Or maybe both could be better!!

Will look into this and see what I come up with!

Original comment by jamesdriscoll71 on 11 Mar 2011 at 9:13

• Changed state: Accepted
• Added labels: Component-Persistence

[GoogleCodeExporter]

The same applies to the SQLite and SqlServerCompact implementations too.

My inclination is that NuGet should create the folders if they don't exist, 
rather than changing the errorLog implementations.

Anyone else got any views on this?

Original comment by jamesdriscoll71 on 13 Mar 2011 at 11:23

[GoogleCodeExporter]

The only reason directories are not auto-created in log implementations is in 
case the required permissions are not granted. It's a precaution against 
blindly calling Directory.CreateDirectory but I imagine if one does a 
Directory.Exists check before then one could add the auto-creation logic. The 
Directory.Exists check is superficial because Directory.CreateDirectory only 
creates if necessary but the subtle reasons for the check would still be 
permissions.

Original comment by azizatif on 15 Mar 2011 at 10:00

[GoogleCodeExporter]

I don't like the idea of the XyzErrorLog creating the folder, because (IMO) non 
NuGet users will be making that choice themselves and ensuring that the folder 
exists.

With the NuGet scenarios, we are forcing a default location choice upon users, 
so we possibly need to deal with the folder creation ourselves.

From what I've seen so far, the easiest way to deal with this is to put a 
"placeholder" in the folder, and NuGet will create it along with the folder.
The trouble is, that NuGet will aggressively delete that folder and its 
contents upon uninstall - I've raised an issue about this 
(http://nuget.codeplex.com/workitem/810) - which is not a pleasant user 
experience.

The other option seems to be to create a post build command that creates the 
folders... but this is far from ideal in the case where the user decides to 
edit things and move the folder to another location. We can't have a build 
command that continually recreates the folder that the user has just deleted!!

My current feeling is to wait and see what the NuGet team do with my issue.
I think we might have to be patient with this before committing to a solution 
that might end up causing us more grief!

Original comment by jamesdriscoll71 on 15 Mar 2011 at 10:21

[GoogleCodeExporter]

I second not committing to solution that might end up causing grief. :)

> we are forcing a default location choice upon users

We're not forcing, just defaulting. :) The App_Data choice is a safe bet as a 
default since ASP.NET will block requests into that folder out of the box and 
without further ado.

Original comment by azizatif on 15 Mar 2011 at 10:28

[GoogleCodeExporter]

The NuGet bug report (http://nuget.codeplex.com/workitem/810) has been Accepted 
and Fixed.
I will therefore press ahead with a solution using a "placeholder" as discussed 
above.

Original comment by jamesdriscoll71 on 7 Apr 2011 at 4:09

• Changed state: Started
• Added labels: Milestone-Release1.2

[GoogleCodeExporter]

Fixed in r822

Original comment by jamesdriscoll71 on 18 Apr 2011 at 6:14

• Changed state: Fixed