I`ve added a service Reference based on a local wsdl file to my .net core 6 application.But the Interface i get from the Reference gives me addidional data types.
If i implement the interface it should give me following method.
public Ack Heartbeat(Heartbeat parameter)
{
(my impl. here)
}
but instead its generating me
public HeartbeatResponse HeartbeatAsync(HeartbeatRequest request)
{
(my impl. here)
}
So for all my methods defined by the interface there is a new datatype with ...Response and ...Request
Ive read that this could have to do something with the setting "always generate message contracts" in the add sercvice reference setings. But i have`nt checked this setting.
Related
I have a ASP .Net Web API controller that I want to take 2 parameters. The first one is an EF context and the second being a caching interface. If I just have the EF context the constructor gets called, but when I add the caching interface I get the error:
An error occurred when trying to create a controller of type
'MyV1Controller'. Make sure that the controller has a
parameterless public constructor.
private MyEntities dbContext;
private IAppCache cache;
public MyV1Controller(MyEntities ctx, IAppCache _cache)
{
dbContext = ctx;
cache = _cache;
}
My UnityConfig.cs
public static void RegisterTypes(IUnityContainer container)
{
// TODO: Register your types here
container.RegisterType<MyEntities, MyEntities>();
container.RegisterType<IAppCache, CachingService>();
}
I would expect that Entity now knows about both types when a request is made for MyV1Controller function it should be able to instantiate an instance since that constructor takes types it knows about but that's not the case. Any idea why?
[EDIT]
Note that I created my own class (IConfig) and registered it and add it to the constructor and it worked, but whenever I try to add the IAppCache to my constructor and make a request to the API I get the error telling me it can't construct my controller class. The only difference that I see is the IAppCache isn't in my projects namespace because it's a 3rd party class but that shouldn't matter from what I understand.
Here are the constructors for CachingService
public CachingService() : this(MemoryCache.Default) { }
public CachingService(ObjectCache cache) {
if (cache == null) throw new ArgumentNullException(nameof(cache));
ObjectCache = cache;
DefaultCacheDuration = 60*20;
}
Check the IAppCacheimplementation CachingService to make sure that the class is not throwing any exception when initialized. that parameterless exception is the default message when an error occurs while trying to create controllers. It is not a very useful exception as it does not accurately indicate what the true error was that occurred.
You mention that it is a 3rd party interface/class. It could be requesting a dependency that the container does not know about.
Referencing Unity Framework IoC with default constructor
Unity is calling the constructor with the most parameters which in this case is...
public CachingService(ObjectCache cache) { ... }
As the container know nothing about ObjectCache it will pass in null which according to the code in the constructor will throw an exception.
UPDATE:
Adding this from comments as it can prove useful to others.
container.RegisterType<IAppCache, CachingService>(new InjectionConstructor(MemoryCache.Default));
Reference here Register Constructors and Parameters for more details.
Most of the DI containers while trying to resolve a type always look for a constructor with maximum number of parameters. That is the reason why CachingService(ObjectCache cache) constructor was being invoked by default. As ObjectCache instance is not registered with Unity, so the resolution fails. Once you force the type registration to invoke specific constructor, everything works.
So if you register IAppCache and force it to invoke CachingService() - parameter less constructor, it will work as expected.
container.RegisterType<IAppCache, CachingService>(new InjectionConstructor());
Registering it this way, will force the parameter less constructor to be invoked and internally it will fall back on whatever the third part library wants to use as default. In your case it will be
CachingService() : this(MemoryCache.Default)
Another option that was mentioned in other answers is to register and pass the constructor parameter your self.
container.RegisterType<IAppCache, CachingService>(new InjectionConstructor(MemoryCache.Default));
This will also work, but here you are taking the responsibility of supplying the cache provider. In my opinion, I would rather let the third party library handle its own defaults instead of me as a consumer taking over that responsibility.
Please take a look at How does Unity.Resolve know which constructor to use?
And few additional information for Niject
https://github.com/ninject/ninject/wiki/Injection-Patterns
If no constructors have an [Inject] attribute, Ninject will select the
one with the most parameters that Ninject understands how to resolve.
For LazyCache version 2.1.2 (maybe even earlier) the existing solution no longer works (no constructor that receives MemoryCache), but it works as simple as:
container.RegisterType<IAppCache, CachingService>(new InjectionConstructor());
This worked with .NET Framework 4.6.1, Unity Abstractions 3.1.0.
I have a query regarding BTDF SSO config setting. I am beginner with BizTalk.
I am looking for SSO storage where credentials are stored and retrieved from SSO. I have built-in app located at C:\Program Files (x86)\Deployment Framework for BizTalk 6.0\Framework\DeployToolsork\DeployTools
Could anyone tell me how to store and retrieve from existing SSO config like SSOSettingsEditor which is the default provided by BTDF.
Using BTDF, you can store your configurations as provided in SettingsFileGenerator.xml in BizTalk SSODB. BTDF automatically store your configuration if IncludeSSO property is set to true in btdfproj file.
If you have provided your credential details in SettingsFileGenerator.xml file then only you will find them in SSODB.
You should use SSOSettingsEditor to retrieve or make changes to the configurations. In SSOSettingsEditor, type in your application name and press enter.
Refer to link: BTDF IncludeSSO
BTDF provides a library for modifying SSO Settings that it uses. The method is uses is slightly different from the default Microsoft sample SSO client, so take care regarding which one you're using.
Per that link, the class provides these methods:
namespace SSOSettingsFileManager
{
public static class SSOSettingsManager
{
public static void WriteSetting(string affiliateApplication, string propertyName, string propertyValue);
}
}
It should be fairly straightforward to call that method once you've added a reference to the SSOSettingsFileReader.dll in whatever C# project you have generating your password or updating it, i.e.
string newPassword = GenerateMyPassword();
SSOSettingsFileManager.SSOSettingsManager.WriteSetting("MyApplicationName", "Password", newPassword;);
You could also look at the source of how he's doing it if you want to implement the method yourself.
I have a class library used in windows (WPF) and web (ASP.NET) context. The library has settings that are rather user-scoped, if used in windows context and that have to be application-scoped, if used in web context. I would like to declare them as user-scoped and use the default values as “pseudo-application-scoped”. My problem is, that web applications ban user-scoped settings by throwing a configuration error.
What is the best way to handle this, preferably within the frameworks configuration system?
Ok, facing the unavoidable. There are no user-scoped settings in ASP.NET. Class libraries used in mixed client / server environments shouldn’t use them!
Here is the solution I ended with:
For the usage in a server environment (ASP.NET) all settings of class libraries have to be application-scoped.
I introduce a second set of settings for the usage in client environments (WPF). These settings have property names and types identical to the class libraries property names and types, but they can differ in scope and they are located in my main assembly.
With a small piece of code I extend the libraries setting class to inject the user-scoped settings.
namespace ClassLibrary.Properties
{
using System.Configuration;
public sealed partial class Settings {
private ApplicationSettingsBase injectedSettings;
public void InjectSettings(ApplicationSettingsBase settings)
{
injectedSettings = settings;
}
public override object this[string propertyName]
{
get
{
if (injectedSettings != null)
return injectedSettings[propertyName];
return base[propertyName];
}
set
{
base[propertyName] = value;
}
}
}
}
With this extension I can inject the second settings class into the library settings:
ClassLibrary.Properties.Default.InjectSettings(Application.Properties.Settings.Default);
Have a look at the SettingsProvider class by sub classing it you could create a compatible provider for a ASP.NET environment.
It might make changing the current code quite easy because you can keep the current code but have to add a different provider when in ASP.NET.
This gives a nice overview as well
Today I am digging into WCF Data Service and I have a question regarding this. Can I create WCF Data service as Library and just only create WCF data Service in our existing web app and take reference that library using Factory property so service will deploy with existing web application.
As I know We can create WCF Service Library and only need to take reference that library in Web application like :
Create a WCF Library and implement service contract
Create a Web application and add new item as Wcf service file then take reference WCF library
<%# ServiceHost Service="MyServiceLibrary.MyService" Factory="System.ServiceModel.Activation.WebServiceHostFactory" />
Instead of a service library, I want to create OData service library.
Thanks
Yes, you can host a WCF Data Service in your own assembly - with a few little tricks. I researched this a while ago and came up with these steps / instructions.
Here's how:
put your data model (EF Data Model) into its own assembly, let's call it DataModel
create a new class library project (call it MyDataServiceHost)
add a few references:
your DataModel assembly with the data layer
System.ServiceModel
System.ServiceModel.Web
System.Data.Services.Client
System.Data.Services - you cannot pick this from the usual Add Reference dialog under the .NET category - you need to browse for the assembly file. Find the directory C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0 (or C:\Program Files (x86)\... on a 64-bit machine) and pick the System.Data.Services.dll inside it
add a new class to that class library and call it e.g. YourDataService.cs - it will look something like this:
using System.Data.Services;
using System.Data.Services.Common;
using DataModel;
namespace MyDataServiceHost
{
public class YourDataService : DataService<YourModelEntities>
{
// This method is called only once to initialize service-wide policies.
public static void InitializeService(DataServiceConfiguration config)
{
// TODO: set rules to indicate which entity sets and service operations are visible, updatable, etc.
// Examples:
config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
}
}
}
You can name the class anything you like, and it has to derive from DataService<T> where T is the name of your data model; if you're using Entity Framework, it's the name of your object context class - typically something like (database)Entities or whatever you picked when you created the EDM
add another class to your new project, call it MyDataServiceHost.cs and it will look something like this:
using System;
using System.Data.Services;
using DataModel;
namespace MyDataServiceHost
{
public class MyDataServiceHost
{
public static void LaunchDataService(string baseAddress)
{
Uri[] baseAddresses = new Uri[1];
baseAddresses[0] = new Uri(baseAddress);
using(DataServiceHost host = new DataServiceHost(typeof(YourDataService), baseAddresses))
{
host.Open();
Console.WriteLine("DataService up and running.....");
Console.ReadLine();
host.Close();
}
}
}
}
It instantiates a DataServiceHost, which is derived from WebServiceHost (which in turn is derived from ServiceHost) and it will spin up the WCF Data Service runtime for you.
now you can start up your WCF Data Service from any app using:
MyDataServiceHost.LaunchDataService("http://localhost:4444/YourService");
last thing to remember: the app that you use to launch the WCF Data Service must have the connection string (the EDM connection string, if you're using Entity Framework) in its app.config (or web.config) in order for this to work!
I'm currently trying to get my head around WCF services for an ASP.NET dev environment, and I believe that I'm doing well save for one thing that has me stumped.
Basically, I've got a WCF service set up (let's take the default, with an added constructor):
public class MyService : IMyService
{
public MyService() { /* blah */ }
public DoWork() { /* blah */ }
}
The IMyService interface defines the DoWork() method as an [OperationContract], as it should.
So I've got this service referenced in another project (let's say a [Unit] Test Project), via Add Service Reference on the VS2010 UI. This creates a reference to a MyServiceClient which exposes my WCF service methods, as it should.
However, when I do this in my test project:
ServiceReference.IMyService service;
service = new ServiceReference.MyServiceClient();
... the MyService() constructor does not get called, basically because I'm instantiating a MyServiceClient, not a MyService per se.
How do I go about getting that constructor called? I'm planning to use that for initialization purposes (perhaps grabbing a layer in a tiered implementation, for example?).
That constructor will be called on the server when you make your request from the client.
Creating a "reference" to a web service (and then using the client classes) is very different to referencing a regular .DLL. All of your service code will run on the server-side, but not until the service is invoked...
The only way for the server-side constructor to be called for each request is to set the InstanceContextMode to PerCall (in the ServiceBehavior attribute).