反思，以避免System.Web參考

我有一個共享的報告DLL在Windows和Web都使用。我現在試圖將Windows程序移到.NET 4客戶端配置文件，因此需要避免System.Web引用。反思，以避免System.Web參考

在某些時候，代碼需要獲取網站的目錄或dll的目錄。我使用的代碼是這樣的：

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

是否有使用反射或類似避免的System.Web參考，所以我仍然可以得到適當的路徑的方法嗎？如果是這樣，我該怎麼做？

任何替代品？

編輯我之所以想這樣做，這是我使用，可以採取一個樣式表文件，並將其應用到報告的報告系統（我這樣做是爲所有報告）。作爲一個設置，我以前在DLL本身mystylesheet.repss。所以如果我想改變樣式，我只是改變它在DLL中，它適用於所有報告。那麼就是把合適的repss文件放到windows和網站的根目錄下。找到適合他們的路徑。

試圖在dll中使用相對路徑導致問題。通過報告。\ mystylesheet.repss在Windows中正常工作，但試圖〜/ mystylesheet.repss。\ mystylesheet.repss或其他任何我能從web中的DLL中想到的結果都是在錯誤的目錄中查找「c：\ windows \ system32 \ INETSRV」。

我可以將設置移動到每個不同的窗口和網絡應用程序，並將其傳入完整路徑，看起來倒退如此做，當它真的是一個dll的內部設置。

希望這一切都有道理。

來源

2011-09-22 PeteT

將基本路徑從客戶端代碼傳遞到庫中不是更好嗎？ – Lazarus

我可以做到這一點，但寧願不必。我只是添加一個編輯來解釋我爲什麼要這樣做。 – PeteT

爲什麼不使用相對於AppDomain.BaseDirectory的路徑。

這將是ASP.NET Web應用程序的根目錄，以及包含控制檯或WinForms應用程序的可執行文件的目錄。

對於其他應用程序類型，它通常是一個合理的默認位置：例如，在VSTO 2005應用程序中，它將是包含應用程序的VSTO託管程序集的目錄，而不是指向Excel的路徑可執行文件。

如果合適，您可以支持可選的配置設置（例如appSetting），以允許DLL的調用者指定替代位置，同時默認爲基本目錄。

另一種選擇是讓你的調用者指定樣式表文件的路徑，它可以是絕對的或相對的。如果是相對的，則相對於AppDomain.BaseDirectory。

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

注意，如果使用相對路徑，這將是相對於當前工作目錄，它可以在應用程序的生命週期內改變，是不一樣的應用程序根目錄。

來源

2011-09-22 11:02:12 Joe

這已排序我的問題。謝謝，我認爲AppDomain會在IIS中提供不同的東西，但它會獲得正確的路徑到我的網站。 – PeteT

如果用於確定位置的機制應該取決於上下文，那麼調用程序將它作爲構造函數或方法參數或類似的東西傳遞是合適的。無論這只是一條直線路徑還是像Func<string, string>這樣的「路徑解析器」，都將取決於您需要做什麼。

來源

2011-09-22 10:31:32

有一次我不同意Jon Skeet。儘管在某些情況下讓調用者提供路徑解析器是可取的，但似乎不希望強制他這樣做，而不是提供合理的默認值，例如使用「AppDomain.BaseDirectory」的默認值。 – Joe

@Joe：這取決於它如何被使用，真的。我非常熱衷於使這種依賴顯式化 - 讓調用者決定要做什麼，並在文檔中指出「AppDomain.BaseDirectory」*可能是適當的。這有點像時區 - 我有意*不*默認到Noda Time的任何特定時區，以便讓來電者明確地做出選擇。 –

這是一個權衡當然。但是我認爲，如果有合理的默認值可用，那麼API通常更易於使用。 Noda時間可能會解決比更一般的DateTime和DateTimeOffset類型更具體的用例，因此您的選擇可能是正確的。但另一個比喻可能是'String.Format'，默認當前的文化是恕我直言，正確的選擇，但不是每個人都會同意。在考慮「Convention over Configuration」設計模式時，這有點類似於權衡，但任何討論最好留給程序員堆棧交換站點。 – Joe

反思，以避免System.Web參考

回答

相關問題