Reflection to avoid System.Web reference

Question

I have a shared reporting dll that is used in both windows and web. I am now trying to move the windows programs to .NET 4 client profile so need to avoid System.Web references.

At some points the code needs to get the directory of the website or the directory of the dll. I used code something like this:

string path;
if (HttpContext.Current != null)
{
    path = HttpContext.Current.Server.MapPath("default.aspx");
}
else
{
    path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
}

Is there a way to use reflection or similar to avoid the System.Web reference so I can still get the appropriate path? If so how do I do it?

Any alternatives?

EDIT The reason I want to do this is I use a reporting system that can take a stylesheet file and apply it to reports (I do this for all reports). As a setting I previously had in the dll itself mystylesheet.repss.So if I wanted to change styles I just change it in the dll and it is applied to all reports. It was then just a case of dropping the appropriate repss file into the root directory on windows and the website. And finding the appropriate path to them.

Trying to use relative paths with the dll results in issues. Passing the report.\mystylesheet.repss works fine in Windows but trying ~/mystylesheet.repss .\mystylesheet.repss or anything else I can think of from the dll in web ends up looking in the wrong directory "c:\windows\system32\inetsrv".

I could move the setting out to each different windows and web app and pass it in with the full path worked out it seems backwards to do it that way when it is really an internal setting for the dll.

Hope that has all made sense.

Wouldn't it be better to pass the base path into the library from your client code? — Lazarus, Sep 22 '11 at 10:31
I can do that but would prefer not to have to. I am just adding an edit to explain why I want to do this. — PeteT, Sep 22 '11 at 10:42

Joe · Accepted Answer · 2011-09-22T11:16:26.427

Why don't you use paths relative to AppDomain.BaseDirectory.

This will be the root directory of the web application for ASP.NET, and the directory containing your executable for a Console or WinForms application.

For other application types, it will generally be a sensible default location: for example, in a VSTO 2005 application, it will be the directory containing the VSTO managed assemblies for your app, not, say, the path to the Excel executable.

If appropriate, you could support an optional configuration setting (e.g. appSetting) to allow the caller of your DLL to specify an alternate location, while defaulting to the base directory.

Another option is to allow your callers to specify a path to the stylesheet file, which can be absolute or relative. If relative, make it relative to AppDomain.BaseDirectory.

if (!Path.IsPathRooted(stylesheetPath))
{
     stylesheetPath = Path.Combine(
                          AppDomain.CurrentDomain.BaseDirectory, 
                          stylesheetPath);
}
...

Note that if you use a relative path, it will be relative to the current working directory, which can change during the lifetime of an application, and is not the same as the application base directory.

That has sorted my issue. Thanks, I thought AppDomain would come up with something different in IIS but it gets the correct path to my site. — PeteT, Sep 22 '11 at 11:25

score 0 · Answer 2 · answered Sep 22 '11 at 10:31

0

If the mechanism for determining the location should depend on the context, it sounds like it would be appropriate for the caller to pass it in as a constructor or method parameter or something similar. Whether that's just as a straight path or something like a Func<string, string> as a "path resolver" will depend on exactly what you need to do.

answered Sep 22 '11 at 10:31

Jon Skeet

1,421,763
867
9,128
9,194

For once I have to disagree with Jon Skeet. While it may be desirable in some circumstances to let the caller provide a path resolver, it seems undesirable to *force* him to do so rather than providing a sensible default such as one using `AppDomain.BaseDirectory`. – Joe Sep 22 '11 at 11:11
@Joe: It depends on how it's being used, really. I'm quite keen on making this sort of dependency explicit - make the caller decide what to do, and point out in the documentation that `AppDomain.BaseDirectory` *may* be appropriate. This is a bit like time zones - I've deliberately *not* defaulted to any particular time zone in Noda Time, to make the caller make the choice explicitly. – Jon Skeet Sep 22 '11 at 11:14
it's a trade-off of course. But I think that APIs are more generally useable if a sensible default is available. Noda Time is probably addressing a more specific use case than the more general DateTime and DateTimeOffset types, so your choice may well be right. But another analogy might be `String.Format`, where defaulting to the current culture is, IMHO, the right choice, though not everyone would agree. It's somewhat similar to the tradeoffs when considering the "Convention over Configuration" design pattern - but any discussion is probably best left to the Programmers Stack Exchange site. – Joe Sep 22 '11 at 19:58
@Joe: Actually quite the reverse - Noda Time is much more *general* than DateTime and DateTimeOffset. And I'm glad you brought up string.Format, because I think the current culture is a really *bad* choice. It's certainly terrible when parsing or formatting machine-readable values. The invariant culture would be a better default IMO - or none at all, and force the user to make a decision. – Jon Skeet Sep 22 '11 at 20:01
Noda Time is certainly richer, but I'd argue that this makes it less accessible, and hence less generally useable. Similarly I think that defaulting to the current culture for formatting makes APIs more accessible, though I understand your POV having seen the frequent problems it causes. – Joe Sep 22 '11 at 20:07
@Joe: Noda Time forces you to ask the questions you *should* be asking yourself anyway. Yes, it's easier if you don't bother thinking about whether you're actually trying to represent a date and time with a particular time zone, or a local one... right until the moment it breaks and you don't understand why. And defaulting to the current culture may be appropriate for user interface work, but for machine-to-machine work it's almost *always* the wrong decision. When a "default" is inappropriate for a significant portion of use cases, there shouldn't be a default IMO. – Jon Skeet Sep 22 '11 at 20:11

Reflection to avoid System.Web reference

2 Answers2