This MSDN article recommends always to provide a namespace to a ServiceContract and DataContract.
Examples usually have a "schema" prefix and a URI type pattern for the namespace such as
Namespace="urn:WCFEssentials/Samples/2008/12"
instead of a traditional C# namespace with dot-notation such as
Namespace="MyNamespace.MyDataClasses"
What is the suggested format the namespace property? Do we need the schema prefix? Why is this format suggested?
Here are some additional suggestions from MSDN:
The namespace can be any string
but is traditionally a Uri representative of the company or application domain
and includes a year and month to support versioning scenarios.
For DataContracts, the namespace is often similar to the ServiceContract namespace
but uses using a “schemas” uri section
Example Service Contract with Namespace
[ServiceContract(Namespace="urn:CompanyName/ApplicationName/YYYY/MM")]
[ServiceContract(Namespace="urn:BigFont/EmailSystem/2014/03")]
Example Data Contract with "Schema" Segment in Namespace
[DataContract(Namespace="urn:CompanyName/Schema/YYYY/MM")]
[DataContract(Namespace="urn:BigFont/Schema/2014/03")]
Thank you to John Saunders or getting me started.
It's an XML Namespace. Those can either be in the urn: format or they can be URLs.
Related
While looking at a variety of examples and how-tos for creating WCF services I notice that some people decorate the interface code with attributes and others decorate the implmentation code. I understand decorating the interface with [ServiceContract] but where is the proper place for things like [WebGet] or [WebInvoke] or [AspNetCompatibilityRequirements]?
Most attributes' proper location is not up the developer, but specified by the WCF documentation. See the examples in these pages for proper attribute usage.
WebGet - interface, operation contract:
http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webgetattribute.aspx
WebInvoke - interface, operation contract:
http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webinvokeattribute.aspx
AspNetCompatibilityRequirements - service implementation:
http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.aspx
Since you are coding the class definition, it's best to place them in the same file as the class implementing them. Putting them on the interface makes it hard to remember how the method is to be used. With it right on the class and method implementations, you can't forget!
I am writing a WCF client to communicate with a JAX-WS web service. Basically communication with the service works. But when investigating the XML generated by the WCF client there are some elements missing. All the properties are correctly generated and I have set them in my code. I am new to WCF and web services in general so I have problems to analize what could be wrong here. What could cause the missing elements in the XML? The only thing I noticed all these missing properties have in common is that they are enumeration types. But other than that I found nothing. For example there is a enumeration for country codes. An entitity has 3 properties of that enumeration type. Only one of the 3 related elements is generated in the XML.
Thanks for your help.
As the OP discovered, when a WCF client (including proxy classes generated by the XSD.exe utility) imports an enumerator from the WSDL or XSD, the proxy also has a corresponding bool property. For an enumeration element named 'Foobar' there is also 'FoobarSpecified' which must be set to true or WCF will not serialize the data element.
This is still true 6 years after the question was asked, even when using the new WCF Client in .NET Core and Visual Studio 2017, and it isn't especially obvious, so I thought I'd promote the OP's comment response to wiki answer.
This is most likely occuring because WCF contracts treat enums differently. For data contracts you mark the class with a DataContract attribute and the members with a DataMember attribute. What's not as well known is that enums have their own attribute called EnumMember which WCF uses to serialize them properly.
There is an MSDN article called Enumeration Types in Data Contracts which goes over the usage in greater detail. The example code from the article shows how a contract with an enum should look:
[DataContract]
public class Car
{
[DataMember]
public string model;
[DataMember]
public CarConditionEnum condition;
}
[DataContract(Name = "CarCondition")]
public enum CarConditionEnum
{
[EnumMember]
New,
[EnumMember]
Used,
[EnumMember]
Rental,
Broken,
Stolen
}
Note that in their example (which I've included above) you can set just a subset of the enum values as part of the data contract if that's a requirement.
In addition to this any property that is not tagged with the DataMember attribute will not serialize over the wire. This should be the checklist to ensure that serialization works for WCF:
Check that classes are marked with the DataContract attribute.
Check that properties are marked with the DataMember attribute.
Check that the individual enum values are marked with the EnumMember attribute.
MVC 4 Beta project fails to compile after upgrading to .Net 4.5.
This happens due to conflict between
System.ComponentModel.DataAnnotations.CompareAttribute and System.Web.Mvc.CompareAttribute
System.ComponentModel.DataAnnotations.CompareAttribute MSDN documentation says:
Provides an attribute that compares two properties.
While System.Web.Mvc.CompareAttribute MSDN documentation says:
Provides an attribute that compares two properties of a model.
What is the difference between the two and when it would be "smarter" to use each of them?
10x.
So, looking at the MSDN documentation and doing a literal comparison of the two classes, I noticed both classes are derived from System.ComponentModel.DataAnnotations.ValidationAttribute. In fact, the classes are almost exactly the same. The only notable difference is that the MVC version also implements IClientValidatable which adds the following properties:
FormatPropertyForClientValidation - (static member) Formats the property for client validation by prepending an asterisk and a dot.
GetClientValidationRules - Gets a list of compare-value client validation rules for the property using the specified model metadata and controller context.
As for which class you should use, if the model will be directly bound to a view, use the MVC version so that you can take advantage of the client-side validation. However, if you're using ViewModels, you can stick with the ComponentModel class and avoid the unnecessary overhead of the additional properties. Your call!
System.Web.Mvc.CompareAttribute
System.ComponentModel.DataAnnotations.CompareAttribute
Microsoft Connect work-around is:
Posted by GavK on 6/17/2012 at 5:13 AM
I added a full reference to [System.Web.Mvc.Compare(...)] rather than
just using [Compare(...)]
Works for me in VS 2012...
Vinney nailed most of it with the exception of which one you should use...
The reason you have a conflict after changing your target framework to 4.5 is because prior to .NET 4.5 there was no CompareAttribute class in the System.ComponentModel.DataAnnotations namespace and the class defined under System.Web.Mvc filled the gap. Therefore, as an example if you were using [Compare] and [Required] attributes in your model class prior to updating your target framework you ended up with a conflict when you upgraded.
Assuming you are not using anything else in the System.Web.Mvc namespace in your model class, you should remove that using statement and let it rely on the System.ComponentModel.DataAnnotations namespace. Unobtrusive client-side validation will continue to work exactly as it did before, just as it does for other attributes that you decorate your model's properties with from the same namespace (eg Required).
If you wish to be explicit about the reference, you can simply add this line:
using CompareAttribute = System.Web.Mvc.CompareAttribute;
Using Visual Studio 2013 (MVC 5 project, .NET 4.5) the IntelliSense suggests that System.Web.Mvc.CompareAttribute is deprecated.
I used System.ComponentModel.DataAnnotations.CompareAttribute and it works fine.
It also does the client-side validation!
On this post, they also suggest another solution, which is to move the reference of the preferred namespace for Compare() inside the model's namespace. Eg. if you prefer to use Compare from System.Web.Mvc, use:
using System.ComponentModel.DataAnnotations;
namespace MyProject.MyViewModel
{
using System.Web.Mvc;
The compiler will search inside the model's namespace first.
Is their a way to set up interception with the Ninject.Extensions.Interception extension so it applies it to all classes in a Namespace or assembly?
Currenlty i have to do it per class like this
Kernel.Bind<MyClass>().ToSelf().Intercept().With<ILoggerAspect>();
Ninject.Extensions.Conventions should take care of this (though it doesn't influence any explicit Bindings you may have not generated via the conventions module).
See the Ninject.Extensions.Conventions wiki.
I'm writing an implementation of IWsdlExportExtension and I've collected a list of PropertyInfo instances that need their corresponding XSD declarations to be modified. In order to do this, I need to determine their XML namespace.
I understand that looking at the DataMemberAttribute is not enough. Is there a built in method in the WCF libraries that can provide that information? Otherwise, would the algorithm look like to determine this?
I believe what you want is get an instance of the ContractDescription class. This class has a namespace property.
You can get an instance of this class using one of the GetContract methods. They have a Type parameter. So In your case, you could use this kind of call:
string myNamespace = ContractDescription.GetContract(
typeof(IMyService),
myPropertyInfo.DeclaringType).Namespace;
NOTE: you will also need the contract type (represented in this sample by typeof(IMyService))