I am having problems sharing my public enum class from my WCF service down to my client program.
(I want to be able to access every enum attributes from my client program). (I have added my service as i Service Reference).
(For testing I only have two EnumMemer - I know..)
I have this in my Service.svc.cs file:
namespace ITHelperService
{
[DataContract]
public class Service : IService
{
[DataMember]
public CommandsEnums comands;
[DataContract(Name="CommandsEnums")]
public enum CommandsEnums
{
[EnumMember]
Get_IPConfig,
[EnumMember]
Get_IPConfig_all,
Get_BIOSVersion,
Get_JavaVersion,
Get_RecentInstalledPrograms,
Get_RecentEvents,
Get_WEIScore,
Do_Ping,
Do_NSLookup
}
}
}
And this is my IService.cs file:
namespace ITHelperService
{
[ServiceContract]
[ServiceKnownType(typeof(ITHelperService.Service.CommandsEnums))]
public interface IService
{
}
}
I have searched the Internet about this problem and it seems that the above should do the trick.
But I can't access them in my client program. It doesn't show up in the intellisense.
Any input please?
I think you are confusing a few things here.
The IService does not have any Operations in it. A ServiceContract should have a few OperationContracts, that you implement in your Service class.
The Implementation of your IService, the Service class, should NOT be a DataContract! It is your implementation of the IService interface.
The Enum CommandsEnums should maybe not be inside the implementation of the Service class, as Simon pointed out.
I would suggest smth like this:
IService.cs file:
namespace ITHelperService
{
[ServiceContract]
[ServiceKnownType(typeof(ITHelperService.Service.CommandsEnums))]
public interface IService
{
[OperationContract]
void Test();
}
}
Service.svc.cs file:
namespace ITHelperService
{
[DataContract]
public class Service : IService
{
public void Test()
{
// This is the method that you can call from your client
}
}
[DataContract(Name="CommandsEnums")]
public enum CommandsEnums
{
[EnumMember]
Get_IPConfig,
[EnumMember]
Get_IPConfig_all,
Get_BIOSVersion,
Get_JavaVersion,
Get_RecentInstalledPrograms,
Get_RecentEvents,
Get_WEIScore,
Do_Ping,
Do_NSLookup
}
}
Your enum shouldn't be included with the server-side code. If you want to share common code, then put it in a common location. That way both the client and server can reference it.
Related
I have a very strange and obscure issue with WCF services that I was hoping to get some insight on:
I am working a WCF service that we are building to replace one that we no longer have source code for. For some reason, in the new WCF service, everything is forced through a single paramater called "request". Using the WCF test client, this is what it looks like
On the "correct" service, this is what it looks like:
Is there any reason why this would be happening? I've defined all of the requests as follows:
[ServiceContract]
public interface IMyService
{
[OperationContract]
string SomeRequest();
}
Which seems correct, but there may be something I've overlooked that is causing this.
In your original WCF service, there is a request function parameter, and it has a definition similar to the following:
[ServiceContract]
public interface IMyService
{
[OperationContract]
Request SomeRequest(Request request);
}
[DataContract]
public class Request
{
string documentId;
[DataMember]
public string DocumentId
{
get { return documentId; }
set { documentId = value; }
}
}
In the new wcf service:
[ServiceContract]
public interface IMyService
{
[OperationContract]
string SomeRequest(string documentId);
}
So this is because the function parameters are different. Originally your parameter was class, but later changed to string, so the display in WCFTestClient is different.
My interface look like this:
[ServiceContract]
public interface IMyService
{
[OperationContract]
myConnectedService.SomeComplexResponseType someMethod(myConnectedService.SomeComplexRequestType request);
}
My implementation look like this:
public class MyService : IMyService
{
myConnectedService_client client = new myConnectedService_client();
public myConnectedService.SomeComplexResponseType someMethod(myConnectedService.SomeComplexRequestType request)
{
myConnectedService.SomeComplexResponseType response = client.connectedServiceMethod(request);
return response ;
}
}
The error i get when i am trying to run my service:
Failed to add a service. Service metadata may not be accessible. Make sure your service is running and exposing metadata.
and
error CS0644: 'System.ComponentModel.PropertyChangedEventHandler' cannot derive from special class 'System.MulticastDelegate'
I'm updating a few web services that have some components in common, so I thought that by creating a library that has that code in it, it could ease maintenance. When using a class from said library, the web service forces me to call the method with its proxy class.
Since the system is somewhat old, I can't change the architecture. The compilation is made in x64. I've already attempted to change the "Reuse types in referenced assemblies".
Referencing a class "x" from the "y" library on a web service "w" forces me to use the class "w.x" instead of "y.x" on a service method call.
Best regards,
Fábio Jesus
The code that I can provide is the following:
Library
namespace Library1
{
public class Class1
{
}
}
Service
namespace Services
{
[ServiceContract]
public interface Service
{
[OperationContract]
void Method(Library1.Class1 cc);
}
}
Client
namespace Client
{
public class ClientControl : PageControl
{
public void Execute(){
using(var _service = new Services.Service){
var cc = new Library1.Class1();
_service.Method(cc);
}
}
}
}
I have a WCF service method that sends back a MembershipCreateStatus (System.Web.Security) to the calling method. When I look at the service definition it has recreated the enum as a type of MyProject.MyWebService.MembershipCreateStatus so it is essentially a completely different object.
Is there a way in which I can tell the service definition to use the System.Web.Security class instead, even though it is this within the WCF service?
You you can. You need to use the KnownTypeAttribute class to decorate the DataContract in your WCF Service to specify that the enum is of type System.Web.Security.MembershipCreateStatus I'm not aware of the details of your environment but in general unless you control both the WCF service and the consuming clients, I would carefully research the support requirements and the possibility of a future change to the enum causing backwards compatibility issues with clients that are consuming this enum. Also to consider is a scenario where a non .NET client could consume your WCF service. In that case you need to consider if using the System.Web.Security.MembershipCreateStatus enum is a good idea versus implementing your own statuses for Member creation. Here is another question on StackOverflow with a good discussion on this topic.
For example see the following code below
[ServiceContract]
public interface IMembershipService
{
[OperationContract]
CreateMemberResponse CreateMember(ApplicationUser userToCreate);
}
[DataContract]
[KnownType(typeof(System.Web.Security.MembershipCreateStatus))]
public class CreateMemberResponse
{
[DataMember]
public MembershipCreateStatus Status { get; set; }
}
[DataContract]
public class ApplicationUser
{
public bool ReturnSuccess { get; set; }
public ApplicationUser()
{
ReturnSuccess = true;
}
}
You can write a test against this service as follows and this test will succeed.
[TestClass]
public class MembershipStatusInvocationTests
{
[TestMethod]
public void CreateMemberShouldReturnMembershipCreateStatusEnum()
{
var client = new MembershipServiceClient();
var response = client.CreateMember(new ApplicationUser {ReturnSuccess = true});
Assert.IsInstanceOfType(response.Status, typeof(System.Web.Security.MembershipCreateStatus));
}
}
For more information on the KnownTypeAttribute class see here
recently have been successful getting my IIS hosted WCF service to work with basic authentication.
Since successfully implementing that. I have noticed that property values are not remembered.
Here is some code:
[ServiceContract]
public interface IEcho
{
string Message { [OperationContract]get; [OperationContract]set; }
[OperationContract]
string SendEcho();
}
public class EchoProxy : IEcho
{
public string Message { get; set; }
public string SendEcho()
{
return string.Concat("You said: ", Message);
}
}
public class EchoService : System.ServiceModel.ClientBase<IEcho>, IEcho
{
//-- ..... CONSTRUCTORS OMITTED ....
public string Message
{
get { return base.Channel.Message; }
set { base.Channel.Message = value; }
}
public string SendEcho()
{
return base.Channel.SendEcho();
}
}
Here is the console and the result:
EchoService client = new EchoService("SecureEndpoint");
client.ClientCredentials.UserName.UserName = "test";
client.ClientCredentials.UserName.Password = "P#ssword1";
client.Message = "Hello World";
Console.WriteLine(client.SendEcho());
Expected Result: You said: Hello World
Actual Result: You said:
I have Uploaded the sandbox project to my skydrive. I have included a SETUP.txt in the API project.
Click here to download.
How can I get properties to work?
thank you
I have never seen WCF contract used with a property to transfer data. i.e. the Message property. AFAIK its just not possible.
My recommendation would be to keep the concerns that are part of the contract separate, i.e. Operation and Data.
[ServiceContract]
public interface IEcho
{
[OperationContract]
string SendEcho(string Message);
}
Or
[ServiceContract]
public interface IEcho
{
[OperationContract]
string SendEcho(Message message);
}
[DataContract]
public class Message
{
[DataMember]
public string Message {get; set;}
}
At some later point you may wish to change the Message Object.
[DataContract]
public class MessageV2 : Message
{
[DataMember]
public DateTime Sent {get; set;}
}
While this changes the contract, changes like this can be backwardly compatible if managed carefully.
To understand what's happening, you need to know how the lifetime of the service object you're connecting to is configured. A good starting point is the MSDN article on Sessions, Instancing, and Concurrency.
For example, with InstanceContextMode.PerCall, a new service object will be created for each call, so no properties of the service object will be remembered between calls.
At the other end of the scale, InstanceContextMode.Single means a single instance handles all client requests for the lifetime of the application. In this case properties set by one client will be visible to all clients, not usually desirable.
In general, I would recommend using a stateless service object. But if you want a stateful service object (e.g. one with properties), you should use InstanceContextMode.PerSession, and (important) use a binding that supports sessions.
While I agree with #JTew that you shouldn't generally expose operations as properties, you will have the same problem if you try to use an object that stores state between calls in another way (such as a private field). I.e. the following would have exactly the same problem:
[ServiceContract]
public interface IEcho
{
[OperationContract]
void SetMessage(string message);
[OperationContract]
string GetMessage();
... etc ...
}