Ответ Johann, IMO является правильным.
Он работает таким образом, потому что когда вы отправляете сообщения SOAP, элементы должны иметь пространство имен, иначе WCF не знает, как десериализовать SOAP в Контракт пользовательских данных из-за несоответствия пространства имен.
В C # эти два объекта различаются, потому что они находятся в разных пространствах имен ...
namespace UserServices
{
public class User
{
public string FirstName { get; set; }
}
}
namespace TempuriServices
{
public class User
{
public string FirstName { get; set; }
}
}
Пространство имен в XML / SOAP служит с той же целью, чтобы объекты были из одного и того же «тела» / «компании» / «организации» / «домена» и т. д.
. Из того, что я нашел, когда я создаю службы SOAP, я как правило, сохраняют все мои контракты с данными, контракты на обслуживание и пространства имен имен в одном и том же пространстве имен, например « http://mycompany.com/services/serviceName "
вот некоторые большие ресурсы ... Эквивалентность контракта данных => http://msdn.microsoft .com / ru-ru / library / ms734767.aspx Оптимизация версий контрактов данных => http://msdn.microsoft.com/en-us/library/ms733832.aspx
Надеюсь, это поможет.
Невозможно.
Вся цель HttpContextBase
- абстрагироваться от зависимости от конкретного HttpContext
класса. В то время как может содержать конкретный HttpContext
(как в случае с httpContextWrapper
), другие реализации могут не иметь абсолютно никакого отношения к HttpContext
.
Вашим лучшим вариантом является определение пользовательской фабрики аннотаций, которая может получить для вас HttpContextBase
, так как вы всегда можете обернуть конкретную HttpContext
в HttpContextWrapper
.
Можно,
var abstractContext = new System.Web.HttpContextWrapper(System.Web.HttpContext.Current);