Насколько я знаю, нет никакого метода, чтобы сделать то, что Вы хотите; по крайней мере, не непосредственно. Я сохранил бы photosLocation
как путь относительно приложения; например: "~/Images/"
. Таким образом, Вы могли использовать MapPath, чтобы заставить физическое местоположение, и ResolveUrl
получать URL (с небольшим количеством справки от System.IO.Path
):
string photosLocationPath = HttpContext.Current.Server.MapPath(photosLocation);
if (Directory.Exists(photosLocationPath))
{
string[] files = Directory.GetFiles(photosLocationPath, "*.jpg");
if (files.Length > 0)
{
string filenameRelative = photosLocation + Path.GetFilename(files[0])
return Page.ResolveUrl(filenameRelative);
}
}
Просто сделайте следующее:
using(var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["MyConn"].ConnectionString))
using(var command = connection.CreateCommand())
{
command.CommandText = "...";
connection.Open();
command.ExecuteNonQuery();
}
Отсутствие вызова dispose в команде ничего плохого не сделает. Однако вызов Dispose на нем подавляет вызов финализатора , заставляя вызов dispose повысить производительность.
Самая безопасная политика - всегда вызывать Dispose ()
для объекта, если он реализует IDisposable
явно или через блок using. Могут быть случаи, когда это не требуется, но его вызов в любом случае не должен вызывать проблем (если класс написан правильно). Кроме того, вы никогда не знаете, когда реализация может измениться, означая, что там, где вызов ранее не требовался, теперь он определенно необходим.
В приведенном вами примере вы также можете добавить дополнительный внутренний блок using для команды. как поддерживающий внешний блок для подключения.
Да, вы должны, даже если эта реализация в настоящее время мало что делает, вы не знаете, как он будет изменен в будущем (например, более новые версии фреймворка). В общем, вы должны избавиться от всех объектов, которые реализуют IDisposable
, чтобы быть в безопасности.
Однако, если операция отложена и вы не контролируете всю область действия (например, при асинхронной работе, или при возврате SqlDataReader
или около того),
Подобные вещи можно найти с помощью Reflector , dotPeek или https://referencesource.microsoft.com/ .
I был небольшой раскопок (я бы посоветовал вам покопаться, хотя, чтобы быть полностью уверенным в остальном, хотя я не очень старался), и похоже, что когда вы убиваете соединение, нет удаления каких-либо детей, связанных с эта связь. Кроме того, на самом деле не похоже, что удаление команды действительно так много. Он установит для поля значение null, отсоединится от контейнера (это может предотвратить управляемую утечку памяти) и вызовет событие (это может быть важно, но я не вижу, кто слушает это событие).
В любом случае. Это'