I have problem with loading mef parts under iis. The load method looks like this:
private void LoadPlugins(string path)
{
var aggregateCatalog = new AggregateCatalog();
var directoryCatalogExe = new DirectoryCatalog(path, "*.exe");
aggregateCatalog.Catalogs.Add(directoryCatalogExe);
var container = new CompositionContainer(aggregateCatalog);
container.ComposeParts(this);
}
The method works perfectly in console application or in cassini. Under iis the parts count is 0 - no error, no exception in event log, nothing...
I have completely no idea what is going on. The path is 100% correct.
I would agree with #stakx assesment. I use a different approach to container creation to make it more environment agnostic. I create an interface:
/// <summary>
/// Defines the required contract for implementing a composition container factory.
/// </summary>
public interface ICompositionContainerFactory
{
#region Methods
/// <summary>
/// Creates an instance of <see cref="CompositionContainer"/>.
/// </summary>
/// <returns>An instance of <see cref="CompositionContainer"/>.</returns>
CompositionContainer CreateCompositionContainer();
#endregion
}
With a default implementation (which works in console apps, service hosts):
public class DefaultCompositionContainerFactory : ICompositionContainerFactory
{
#region Methods
/// <summary>
/// Creates an instance of <see cref="CompositionContainer"/>.
/// </summary>
/// <returns>
/// An instance of <see cref="CompositionContainer"/>.
/// </returns>
public CompositionContainer CreateCompositionContainer()
{
var domain = AppDomain.CurrentDomain;
string path = domain.BaseDirectory;
// Use the base directory from where the application is running.
var catalog = new DirectoryCatalog(path);
// Create the container.
var container = new CompositionContainer(catalog);
return container;
}
#endregion
}
And a web specific implementation:
public class WebCompositionContainerFactory : ICompositionContainerFactory
{
#region Methods
/// <summary>
/// Creates an instance of <see cref="CompositionContainer"/>.
/// </summary>
/// <returns>
/// An instance of <see cref="CompositionContainer"/>.
/// </returns>
public CompositionContainer CreateCompositionContainer()
{
string path = HttpRuntime.BinDirectory;
// Use the base directory from where the application is running.
var catalog = new DirectoryCatalog(path);
// Create the container.
var container = new CompositionContainer(catalog);
return container;
}
#endregion
}
Which I wire up through configuration.
The other thing to consider is that you are passing *.exe as your catalog filter, are you using executable assemblies in your web application?
One possible cause of this might be a wrong value for path.
For example, you should not assume that the current directory will be your code's "bin" directory, so passing "." might be a bad idea.
If that is what you're doing, try specifying a path based on Assembly.GetExecutingAssembly().Location:
// using System.IO;
// using System.Reflection;
string binPath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
LoadPlugins(binPath);
The difference when you are running in a console app or cassini and IIS is the security context.
When running the console app or cassini, the security context is the logged on user, which is you.
When running under IIS the security context is the identity of the application pool, which by default is NETWORK SERVICE.
It is probably that your MEF parts are in a directory that NETWORK SERVICE does not have access too.
Related
I have the following class:
/// <summary>
/// Represents an implementation of the <see cref="IAspNetCoreLoggingConfigurationBuilder"/> to configure the ASP.NET Core Logging.
/// </summary>
public class AspNetCoreLoggingConfigurationBuilder : IAspNetCoreLoggingConfigurationBuilder
{
#region Properties
/// <summary>
/// Gets the <see cref="ILogSource"/> that's used to write log entries.
/// </summary>
public ILogSource LogSource{ get; private set; }
#endregion
#region IAspNetCoreLoggingConfigurationBuilder Members
/// <summary>
/// Sets the log source that should be used to save log entries.
/// </summary>
/// <param name="logSource">The source </param>
public void SetLogSource(ILogSource logSource)
{
LogSource = logSource;
}
#endregion
}
I also have a method in which I create an instance of this class:
/// <summary>
/// Adds logging to the <see cref="IApplicationBuilder"/> request execution pipeline.
/// </summary>
/// <param name="app">The <see cref="IApplicationBuilder"/> to configure the application's request pipeline.</param>
/// <param name="configuration">Builder used to configure the ASP.NET Core Logging.</param>
/// <returns>A reference to this instance after the operation has completed.</returns>
public static IApplicationBuilder UseAspNetCoreLogging(this IApplicationBuilder app, Action<IAspNetCoreLoggingConfigurationBuilder> configuration)
{
var aspNetLoggerConfiguration = new AspNetCoreLoggingConfigurationBuilder();
configuration(aspNetLoggerConfiguration);
// Add the registered ILogSource into the registered services.
_services.AddInstance(typeof (ILogSource), aspNetLoggerConfiguration.LogSource);
// The entire configuration for the middleware has been done, so return the middleware.
return app.UseMiddleware<AspNetCoreLoggingMiddleware>();
}
Notice the first line here, I'm creating an instance of the class.
However, when I inspect this variable in a watch, when my cursor is on line configuration(aspNetLoggerConfiguration); I do get that the variable does not exists in the current context.
Creating an instance of the variable does work when doing it directly in the watch window.
Anyone has a clue?
P.S. It's a DNX project which I'm testing in xUnit. The code is running in 'Debug' mode.
Thats no runtime and no compiling-error.
It's a problem of Visual Studio not beeing able to show the object in a debug-window as it is a runtime-object (something like that).
Another occurence of this problem is in a wcf-service client. Create a new serviceclient Client and try to show client.InnerChannel in the watch window. It won't work. You can however create a temp-object (bool, string, etc..) and write the desired value into it to see your value.
#if DEBUG
var tmpLog = aspNetLoggerConfiguration.LogSource;
#endif
You should see the LogSource in the tmpLog when your mouse is over it.
So I have a typical three tiered application layered as below
DAL -> Repository -> Business -> Web.UI/API
I have been reading this article about registering dependencies by centralizing them via modules.
The web layer only has a reference to Business which only has a reference to the Repo which only has a reference to the lowest DAL layer. In this topology since the UI/API layer knows nothing about the Repository and has no reference to it, I can't register the modules in the Repository in the UI/API layer. Similarly I can't register the modules present in the DAL in the Business layer. What I want to do is start the registration process in the top most layer which then sets off a cascading effect of registrations in subsequent layers.
Typically what this would look like is each layer exposing a RegisterAllModules method and somehow trigger the RegisterAllModules method from the layer below it. Has something like this been done? Or is there another way to do this? At this point I don't know if I should roll my own logic out as I mentioned here above, since I don't know if there is a documented way to do something like this or not. Thoughts on how to best go forward here is what I am looking for.
Thanks.
Mmmm... I don't know if what follows is a proper response, but I'm going to try to give you the tools for a solution that suits your exact requirementes.
have you looked into json/xml module configuration? You do not need to know the assemblies through cross reference, you just need to know the name of the assemblies in app.config (or web.config). E.g: you can register one module for Repositories in the Repo assembly and one module for Business services in the Business.dll. This completely removes the need of cross-referencing the various assemblies (for Module scanning, you will still need references for method calls, but that is expected anyway). See here for details: http://docs.autofac.org/en/latest/configuration/xml.html#configuring-with-microsoft-configuration
if you want to enforce no call is done from (say) UI to Repo, you can leverage the "Instance Per Matching Lifetime Scope" function (see http://docs.autofac.org/en/latest/lifetime/instance-scope.html#instance-per-matching-lifetime-scope). You can use that registration method in order to enforce a Unit-of-work approach. E.g: a Repository can only be resolved in a "repository" LifetimeScope, and only Business components open scopes tagged "repository".
an alternative approach to tagged scopes is in using the "Instance per Owned<>" pattern. In this way, each Business service would require an Owned<Repository>.
Something like:
var builder = new ContainerBuilder();
builder.RegisterType();
builder.RegisterType().InstancePerOwned();
AFAICT, a correct approach would be to register the components through Modules, referenced by the Json/Xml config, and each Module should target specific LifetimeScopes.
When you a class calls the underlying layer, it should open a new LifetimeScope("underlying layer").
I will elaborate further, if you want advice on implementation strategies.
Best,
Alberto Chiesa
Edit:
I didn't knew the "composition root" meaning. Well, thanks for the info!
I favor a SIMPLE configuration file (be it the .config file or a separate .json or .xml file), because I feel that a list of modules to be imported is simpler done through a list than through a class. But this is opinion.
What is not an opinion is that you can import modules from assembly that are not referenced by the "Composition Root" assembly, in a simple and tested way.
So, I would go for Modules for every component registration, but for a textual configuration file for Module registration. YMMV.
Now, let me show you an example of the Unit of Work pattern that I'm using in many live projects.
In our architecture we make heavy use of a Service Layer, which holds responsibility for opening connections to the db and disposing them when finished, etc.
It's a simpler design than what you're after (I prefer shallow other than deep), but the concept is the same.
If you are "out" of the Service Layer (e.g. in an MVC Controller, or in the UI), you need a ServiceHandle in order to access the Service layer. The ServiceHandle is the only class that knows about Autofac and is responsible for service resolution, invocation and disposal.
The access to the Service Layer is done in this way:
non service classes can require only a ServiceHandle
invocation is done through _serviceHandle.Invoke(Func)
Autofac injects the ready to use handles via constructor injection.
This is done through the use of BeginLifetimeScope(tag) method, and registering services (in a module) in this way:
// register every service except for ServiceBase
Builder.RegisterAssemblyTypes(_modelAssemblies)
.Where(t => typeof(IService).IsAssignableFrom(t) && (t != typeof(ServiceBase)))
.InstancePerDependency();
// register generic ServiceHandle
Builder.RegisterGeneric(typeof(ServiceHandle<>))
.AsSelf()
.AsImplementedInterfaces()
.InstancePerDependency();
And registering every shared resource as InstancePerMatchingLifetimeScope("service")
So, an example invocation would be:
... in the constructor:
public YourUiClass(ServiceHandle<MyServiceType> myserviceHandle)
{
this._myserviceHandle = myserviceHandle;
}
... in order to invoke the service:
var result = _myserviceHandle.Invoke(s => s.myServiceMethod(parameter));
This is the ServiceHandle implementation:
/// <summary>
/// Provides a managed interface to access Model Services
/// </summary>
/// <typeparam name="TServiceType">The Type of the parameter to be managed</typeparam>
public class ServiceHandle<TServiceType> : IServiceHandle<TServiceType> where TServiceType : IService
{
static private readonly ILog Log = LogManager.GetLogger(typeof(ServiceHandle<TServiceType>));
private readonly ILifetimeScope _scope;
/// <summary>
/// True if there where Exceptions caught during the last Invoke execution.
/// </summary>
public bool ErrorCaught { get; private set; }
/// <summary>
/// List of the errors caught during execution
/// </summary>
public List<String> ErrorsCaught { get; private set; }
/// <summary>
/// Contains the exception that was thrown during the
/// last Invoke execution.
/// </summary>
public Exception ExceptionCaught { get; private set; }
/// <summary>
/// Default constructor
/// </summary>
/// <param name="scope">The current Autofac scope</param>
public ServiceHandle(ILifetimeScope scope)
{
if (scope == null)
throw new ArgumentNullException("scope");
_scope = scope;
ErrorsCaught = new List<String>();
}
/// <summary>
/// Invoke a method to be performed using a
/// service instance provided by the ServiceHandle
/// </summary>
/// <param name="command">
/// Void returning action to be performed
/// </param>
/// <remarks>
/// The implementation simply wraps the Action into
/// a Func returning an Int32; the returned value
/// will be discarded.
/// </remarks>
public void Invoke(Action<TServiceType> command)
{
Invoke(s =>
{
command(s);
return 0;
});
}
/// <summary>
/// Invoke a method to be performed using a
/// service instance provided by the ServiceHandle
/// </summary>
/// <typeparam name="T">Type of the data to be returned</typeparam>
/// <param name="command">Action to be performed. Returns T.</param>
/// <returns>A generically typed T, returned by the provided function.</returns>
public T Invoke<T>(Func<TServiceType, T> command)
{
ErrorCaught = false;
ErrorsCaught = new List<string>();
ExceptionCaught = null;
T retVal;
try
{
using (var serviceScope = GetServiceScope())
using (var service = serviceScope.Resolve<TServiceType>())
{
try
{
retVal = command(service);
service.CommitSessionScope();
}
catch (RollbackException rollbackEx)
{
retVal = default(T);
if (System.Web.HttpContext.Current != null)
ErrorSignal.FromCurrentContext().Raise(rollbackEx);
Log.InfoFormat(rollbackEx.Message);
ErrorCaught = true;
ErrorsCaught.AddRange(rollbackEx.ErrorMessages);
ExceptionCaught = rollbackEx;
DoRollback(service, rollbackEx.ErrorMessages, rollbackEx);
}
catch (Exception genericEx)
{
if (service != null)
{
DoRollback(service, new List<String>() { genericEx.Message }, genericEx);
}
throw;
}
}
}
catch (Exception ex)
{
if (System.Web.HttpContext.Current != null)
ErrorSignal.FromCurrentContext().Raise(ex);
var msg = (Log.IsDebugEnabled) ?
String.Format("There was an error executing service invocation:\r\n{0}\r\nAt: {1}", ex.Message, ex.StackTrace) :
String.Format("There was an error executing service invocation:\r\n{0}", ex.Message);
ErrorCaught = true;
ErrorsCaught.Add(ex.Message);
ExceptionCaught = ex;
Log.ErrorFormat(msg);
retVal = default(T);
}
return retVal;
}
/// <summary>
/// Performs a rollback on the provided service instance
/// and records exception data for error retrieval.
/// </summary>
/// <param name="service">The Service instance whose session will be rolled back.</param>
/// <param name="errorMessages">A List of error messages.</param>
/// <param name="ex"></param>
private void DoRollback(TServiceType service, List<string> errorMessages, Exception ex)
{
var t = new Task<string>
service.RollbackSessionScope();
}
/// <summary>
/// Creates a Service Scope overriding Session resolution:
/// all the service instances share the same Session object.
/// </summary>
/// <returns></returns>
private ILifetimeScope GetServiceScope()
{
return _scope.BeginLifetimeScope("service");
}
}
Hope it helps!
First of all I wanted to thank all of you for your continuous contributions to the Stack Overflow community! I've been a member of Stack Overflow for years and have come to rely on your input more so than any other source online. Though I try to participate and answer members' questions whenever I can, every once in a while I find myself stuck and in need of help.
Speaking of which I have an unusual code problem. I am writing an API library in C# that needs to be able to be called from WPF/Windows Forms application, but also from within Unit Test code.
The issue is that I need to be able to report (in Excel) on whether each method of the library executed properly when the API is called from within a WPF/windows forms application, along some other metadata and optionally a return type.
When the code is consumed within Unit Tests I don't really care about the reporting, but I do need to be able to produce an Assert on whether the API call executed properly or not.
For instance, if in a Unit Test we have an Test Initialize portion, one of the API calls may be to create a Domain User for the test method to use. Another one may also create a Domain Group, so that the user has proper group membership.
To accomodate the consumption of the API from WPF/WinForms, I've been rewriting every function in the API to return a OperationStep type, with the hopes that when all API calls have executed I would have an IEnumerable<OperationStep> which I can write to a CSV file.
So the question is is there an easier way of achieving what I have done so far? The reporting is extremely tedious and time consuming to code, considering that the API library consists of hundreds of similar methods. Samples are described bellow:
OperationStep<PrincipalContext> createDomainConnectionStep = DomainContext.Current.GetPrincipalContext(settings.DomainInfo);
OperationStep<UserPrincipal> createDomainUserStep = DomainContext.Current.CreateUser(createDomainConnectionStep.Context, settings.TestAccountInfo.Username, settings.TestAccountInfo.Password);
OperationStep<GroupPrincipal> createDomainGroupStep = DomainContext.Current.CreateGroup(createDomainConnectionStep.Context, settings.TestAccountInfo.UserGrupName);
Where the DomainContext is a singleton object whose functionality is to connect to the domain controller and create a user, group, and associate the user to a group.
Note that both the second and the third method call require the output of the first, and therefore warranting the need for having the public T Context within the OperationResult object as described bellow.
The OperationStep object consists of the following properties which are inherited by the IOperation interface with the exception of the public T Context.
public class OperationStep<T> : IOperation
{
/// <summary>
/// Denotes the Logical Name of the current operation
/// </summary>
public string Name { get; set; }
/// <summary>
/// Denotes the stage of execution of the current operation: Setup, Execution, Validation, Cleanup
/// </summary>
public OperationStage Stage { get; set; }
/// <summary>
/// Denotes whether the test step completed properly or failed.
/// </summary>
public OperationResult Result { get; set; }
/// <summary>
/// Denotes the return type of the test method.
/// </summary>
public T Context { get; set; }
/// <summary>
/// Denotes any other relevant information about the test step
/// </summary>
public string Description { get; set; }
/// <summary>
/// If the test step result is failed, this should have the stack trace and the error message.
/// </summary>
public string Error { get; set; }
}
The method calls themselves are a bit bloated and tedious but here is a sample.
public class DomainContext
{
private static volatile DomainContext currentContext;
private static object synchronizationToken = new object();
/// <summary>
/// default ctor.
/// </summary>
private DomainContext() { }
/// <summary>
/// Retrieves the Current DomainContext instance.
/// </summary>
public static DomainContext Current
{
get
{
if (currentContext == null)
{
lock (synchronizationToken)
{
if (currentContext == null)
{
currentContext = new DomainContext();
}
}
}
return currentContext;
}
}
/// <summary>
/// Establishes a connection to the domain.
/// </summary>
/// <param name="domainInfo"></param>
/// <returns></returns>
public OperationStep<PrincipalContext> GetPrincipalContext(DomainInfo domainInfo)
{
OperationStep<PrincipalContext> result = new OperationStep<PrincipalContext>();
result.Name = "Establish Connection to Active Directory";
result.Result = OperationResult.Success;
result.Stage = OperationStage.Setup;
result.Description = string.Format("Domain Name: {0}, Default Containter: {1}", domainInfo.FQDN, domainInfo.Container);
try
{
ContextType contextType = this.GetContextType(domainInfo.DomainType);
PrincipalContext principalContext;
try
{
principalContext = new PrincipalContext(contextType, domainInfo.FQDN, domainInfo.Container);
}
catch
{
throw new Exception("Unable to establish connection to Active Directory with the specified connection options.");
}
if (principalContext != null)
{
bool authenticationResult = principalContext.ValidateCredentials(domainInfo.Username, domainInfo.Password);
if (!authenticationResult)
{
throw new Exception("Unable to authenticate domain admin user to Active Directory.");
}
result.Context = principalContext;
result.Result = OperationResult.Success;
}
}
catch(Exception ex)
{
result.Error = ex.Message;
result.Result = OperationResult.Failure;
}
return result;
}
}
When all method calls have executed theoreticaly I should have an IEnumerable<IOperation> which in the case of a win form I can write in a csv file (to be viewed in MS Excel) or in the case of a unit test I can simply omit the extra info and ignore (other than the method executed successively and the T Context property).
If I understood you correctly - all that OperationSteps are here only for logging. Then why not enable simple .NET logging? Log needed info where it is convenient for you. You can use TraceSource with DelimetedTraceListener to write to .csv file. More than that. You can move logging logic to Strategy class and override its logging methods in your unit test so that instead of logging you call Assert methods.
In VS2010 I have two MVC 2 based web apps within the same solution that also share a common Setup project. One app is a configuration utility for setting up users and variables in the opposing app. Upon installation, the two IIS directories look like this on the user's browser:
App1: http://localhost/App1/Auth/Login
App2: http://localhost/App1/App2/Auth/Login
The problem I'm having is when the user has both apps open at the same time, and logs out of one of them they are also logged out of the opposing app. This is a minor issue, but I've been tasked with correcting it.
From what I can tell, the two apps must be sharing the same Session object, because the logout command method in each controller invokes Session.Abandon() .
Only two controllers have the ability to log out a user; here's the constructor's from those controller's:
App1: namespace App1.Controllers
/// <summary>
/// Functionality related to Assets
/// </summary>
public class AssetsController : Controller
{
private IConfig _config = null;
private IProfileRepository _profiles = null;
private IInspectionRepository _inspections = null;
private ICustomLabelsFactory _labels = null;
private IValidateRepository _validator = null;
/// <summary>
/// Create an instance of the AssetsController which uses the db.
/// </summary>
public AssetsController() : this(Config.Current, new ProfileRepository(Config.Current), new InspectionRepository(), new CustomLabelFactory(), new ValidateRepository()) { }
/// <summary>
/// Create an instance of the AssetsController with the given
/// IInspectionRepository implementation.
/// </summary>
/// <param name="inspections">IInspectionRepository implementation.</param>
public AssetsController(IConfig config, IProfileRepository profiles, IInspectionRepository inspections, ICustomLabelsFactory labels, IValidateRepository validator)
: base()
{
ViewData["_Module"] = "Assets";
_config = config;
_profiles = profiles;
_profiles.ModelState = ModelState;
_inspections = inspections;
_inspections.ModelState = ModelState;
_labels = labels;
_labels.ModelState = ModelState;
_validator = validator;
_validator.CustomLabels = _labels.Assets;
_validator.ModelState = ModelState;
}
App2: namespace App1.App2.Controllers
/// <summary>
/// Handles login/logout functionality
/// </summary>
public class AuthController : Controller
{
private ILoginService _login;
private IUtilityRepository _utility;
/// <summary>
/// Creates the Auth controller using the default User Repository which
/// uses the database.
/// </summary>
public AuthController() : this(new LoginService(), new UtilityRepository()) { }
/// <summary>
/// Creates the Auth controller with the given User Repository.
/// </summary>
/// <param name="userRepository">IUserRepository implementation.</param>
public AuthController(ILoginService loginService, IUtilityRepository utility)
: base()
{
ViewData["_Module"] = "Login";
_login = loginService;
_login.ModelState = ModelState;
_utility = utility;
_utility.ModelState = ModelState;
}
I might be barking up the wrong tree on where to start looking at the code, but I'm hoping someone can see something obvious here that I can't. Or, maybe someone can tell me how to do this differently so there is not a shared Session object involved. I've been working on this on and off for the better part of this week, so any help offered will be greatly appreciated.
You could configure each application to use a different session database in your web.config
EDIT: something like
<sessionState mode="SQLServer" sqlConnectionString="Data Source=.\SQLEXPRESS;User Id=test;Password=test;Application Name=AppName" />
<machineKey
validationKey="SOMEKEY"
validation="SHA1" decryption="AES"
/>
Where somekey is different for each application
A simple, lazy, IIS settings avoiding solution is to open each in a different browser.
I'm creating a custom channel in WCF in order to implement a custom security protocol. No, don't run away! It's not that scary!
Verifying the protocol on the service is relatively simple. The hard part is adding the security information to the request based on the client credentials.
What I want to do is access the ClientCredentials object (the one attached to the ClientProxy in use) from within my channel implementation. Normally, I'd get access to this through the Behaviors property on the ServiceEndpoint instance for the endpoint I'm trying to reach:
var credentials = channel.Endpoint.Behaviors.Find<ClientCredentials>();
However, I can't seem to find a way to access the service endpoint the channel is associated with from within the channel itself - almost zero metadata is available from the ChannelBase class.
Is there a way to get the endpoint my channel is associated with? Is there any alternative way to access the client credentials on the client-side?
Standard security channels don't use ClientCredentials internally. They instead talk with SecurityTokenManager which is constructed from ClientCredentials. I recommend using some disassembler to browse whole implementation.
Generally your BindingElement should build both ChannelLister and ChannelFactory and pass them all information they need.
Implement you own client service.
For example;
using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
public class UserClient : ClientBase<IAsyncESPUserService> , IESPUserService
{
/// <summary>
/// Constructor - No Parameters, this will use a default target endpoint.
/// </summary>
public UserClient() : base() { }
/// <summary>
/// Constructor - Binding and Address Parameters
/// </summary>
/// <param name="binding">How we are communicating.</param>
/// <param name="address">The address we are communicating to.</param>
public UserClient(Binding binding, EndpointAddress address) : base(binding, address) { }
/// <summary>
/// Constructor - Configuration Name Parameter
/// </summary>
/// <param name="endpointConfigurationName">The name of the configuration in ServiceReferences.ClientConfig. </param>
public UserClient(string endpointConfigurationName) : base(endpointConfigurationName) { }
//Implement your async service calls here
}
Now call it...
//Create using the default endpoint
UserClient client = new UserClient();
//Set user name and password with call
System.ServiceModel.Description.ClientCredentials loginCredentials = new System.ServiceModel.Description.ClientCredentials();
loginCredentials.UserName.UserName = "test";
loginCredentials.UserName.Password = "test";
//Attach Credentials, Can't do this in config file
var defaultCredentials = client.ChannelFactory.Endpoint.Behaviors.Find<System.ServiceModel.Description.ClientCredentials>();
client.ChannelFactory.Endpoint.Behaviors.Remove(defaultCredentials);
client.ChannelFactory.Endpoint.Behaviors.Add(loginCredentials);
//Now make a call to a service method...