How to obfuscate WCF proxy classes using Dotfuscator ?
I have downloaded Dotfuscator Pro Edition Trial from their website. I obfuscated my app.exe file ,everything was nicely obfuscated but WCF proxy classes were not. (I ILDASMed the exe).
The WCF Proxy classes are giving away structure of my application.Is there any setting I am missing in Dotfuscator application?
Is there a better way to hide WCF service proxy classes?
One way or another, WCF must be able to bind elements in your service's data contract to your client's proxy classes. There is usually little value is obfuscating the proxy classes and their members, but if you do want to obfuscate them you can explicitly set the name of the types and their members using the Name parameter of the [DataContract] or [DataMember] attributes (eg. [DataMember Name="ID"]). Once you've done this, you can disable the "Types and fields marked as serializable" built-in rule from the Rename -> Built-In Rules tab and ensure that "Compatibility with XML serializer" is checked in the Rename -> Options tab. The caveat to this approach is that the names of the serialized properties are still included in your code (in the attributes), and are still sent over the wire.
If you require more protection and you have control of both the service and the client, a better but more cumbersome option might be to put your service contract in its own assembly and process that with Dotfuscator. Again, disable the "Types and fields marked as serializable" built-in rule from the Rename -> Built-In Rules tab and ensure that "Compatibility with XML serializer" is checked in the Rename -> Options tab. Now reference the resulting service contract DLL from both your service and your client application. The tradeoff with this approach is that the contract members will all have obfuscated names (eg. "a") and you will have to reference them as such in your service and client application code. You can examine the map file Dotfuscator produces in order to make sense of the renamed names.
Related
Let's say that I have a simple WPF or Winforms solution. To that solution I add a new project (based on a class library template , which I then reference in the main project) which is intended to be a data layer containing an entity framework data model. When I create the data model in the new project the connection string that it uses gets added to the app.config file of the main project in the solution.
Now let us say that I want to add two more projects to the solution (both of which will again be based on class libraries) to contain details of WCF services that I wish to use. In each case I add the WCF service by using the ADD Service Reference option from the right click context menu of the projects.
Unlike the data model project though the bindings for the service model get added to the local projects app.config file ass opposed to the app.config file of the main start-up project.
Should I simply copy those bindings to the start-up project's app.config file, or should I copy and then delete, or in fact should I be doing something completely different. Thus far trying combination of the first two suggestions I get error messages connected with endpoint configuration, however my knowledge of WCF is not really sufficiently good to fully understand the MSDN articles that the error list points me to.
Note that if the service references are added to the main project I get no errors whatsoever, so I figure this must be a configuration problem of some description.
Would anyone be able to provide the correct procedure for adding projects that essentially contain no more than a WCF service reference to an existing visual studio solution.
Edit
The screenshot below shows my main app.cofig file after having copied over the bindings configurations from the two service contracts. I'm not sure whether I should have commented out the bit that I did or not, I had thought that by doing so I might get rid of the blue squiggly underlines telling me the following (which I must admit to not understanding):
Warning The 'contract' attribute is invalid - The value 'ErsLiveService.IERSAPIService' is invalid according to its datatype 'clientContractType' - The Enumeration constraint failed.
You're likely getting the blue squigglies because the namespace ErsTestService is defined within the project in which you created the service reference. If the root namespace of that project is MyServiceReferenceProject then try changing the namespace to MyServiceReferenceProject.ErsTestService.IERSAPIService.
I have a business object that comes from a WCF service. I know that I can extend that business object by creating a partial class on the client. However, is it possible to extend a property that comes from the generated business object. For example, let's say that the business object has a property called Name. What I want to do is, on the client, to mark this property with the [DisplayAttribute].
Any help would be greatly appreciated.
Never used it for attributes, but I often use the pre-compiler statements to hide Silverlight/Client side code, when it compiles on the server. For Example, this is often done to get to EntityState on both the server and client side:
#if SILVERLIGHT
using System.ServiceModel.DomainServices.Client;
#else
using System.Data;
#endif
SILVERLIGHT is defined on the client side, but not on the Server side projects (conditional compilation symbol - project properties, Build tab).
I haven't tried it, but I'm thinking this might work with attributes?
David Betz describes in his article how to create reference to WCF without using "Add Service Reference" option:
http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2
Once WCF service is created, these are the statements within the silverlight:
BasicHttpBinding basicHttpBinding = new BasicHttpBinding();
EndpointAddress endpointAddress = new EndpointAddress("http://localhost:1003/Person.svc");
IPersonService personService = new ChannelFactory<IPersonService>(basicHttpBinding, endpointAddress).CreateChannel();
...
How does one references the types (such as IPersonService interface) created in WCF from Silverlight when I do not use "Add Service Reference" to buid proxies?
Idea is to reference assemblies that contain WCF data contracts in silverlight application, and to do that you need to fool VS so it thinks assembly is a SL assembly, he describes this in detail here
http://www.netfxharmonics.com/2008/12/Reusing-NET-Assemblies-in-Silverlight
and its not so easy, here is what needs to be done
Just use the same ILDasm/Edit/ILAsm
procedure already mentioned to tell
the assembly to use the appropriate
Silverlight assemblies instead of the
.NET assemblies. This is an extremely
simple procedure consisting of nothing
more than a replace, a procedure that
could easily be automated with very
minimal effort. It shouldn't take you
much time at all to write a simple
.NET application to do this for you.
It would just be a simple .NET to
Silverlight converter and validator
(to test for assemblies not supported
in Silverlight). Put that application
in your Post Build Events (one of the
top 5 greatest features of Visual
Studio!) and you're done. No special
binary hex value searching necessary.
All you're doing is changing two well
documented settings (the public key
token and version).
Second solution is a file level solution , you use add link option on files that contain your required data contracts implementations to SL and make sure they only contain types that allow to build SL and dont reference a lot of external assemblies , usually those conditions should be met for WCF services & data contracts.
I can write more but it would be just the copy paste from that link
You also have to split all methods declaration in you IPersonService according to Async pattern (BeginXXX/EndXXX) since Silverlight supports only asyncronous WCF (even in background threads).
As a help to do this, you may add Service Reference, then copy generated IPersonService (all methods will be decoupled) from Reference.cs. Then you may remove the reference.
However, if your service contract is often changed, you have to repeat Add-Service procedure again, and starting from this, I would say, it's easier just use Add-Service-Reference feature, rather than sharing the contract with your app server.
Only one thing that I would like detect. Often you need in namespaces with more complex support of NET within your WCF service. Therefore you must have real reasons to reference to Silverlight subset within your WCF service (or service library). There are many ways to
use so named traditional ways by Add Service Reference. They are presented in good article enter link description here.
I need to generate service proxies for multiple WCF services within the same namespace, which is not possible when using the Add Service Reference function of Visual Studio.
How can I do this in an automated way? I've considered using SLsvcUtil, but that would require that I make sure that I have my WCF services accessible, and, assuming I'm using the ASP.NET Development Server, I'd need to manually check the URL.
Ideally, I'd have some way of specifying an assembly, a service type, the configuration (web|app.config) and a target namespace, and then my code would be generated. Any Ideas?
Edit
To clarify, I'm trying to solve the same problem that is outlined in this connect issue:
http://connect.microsoft.com/VisualStudio/feedback/details/426791/adding-multiple-service-references-from-same-application-should-not-require-multiple-namespaces
I want a no-hassle, automated way to generate service proxies within a single namespace. It's unacceptable for me to have to specify a unique namespace for each service reference. Using SLsvcUtil is an option, but it requires that I have my service up-and-running so it can read the metadata - which is a problem because I don't always have the latest version of the service running at any given point in time.
The "Add Service Reference" functionality in VS handles this well - it automatically hosts the service just long enough to grab the metadata, and then generates the service contract interfaces and proxies. Once again, it requires that each service be code-gen'd in its own, unique namespace, which I don't want.
All I need is a way to generate the service proxies with a single, shared namespace, without having to go through the hassle of manually hosting and firing up an instance of my services. Ideally, I'd just double click a script file.
What I normally do is to inform a composite namespace. When the "Add Service Reference" dialog pops up, I put in the namespace something like Services.ServiceA or Services.ServiceB. Then all service namespaces share the common root Services.*.
If I'm understanding the question correctly, you're concerned because the way Add Service Reference functions, the ServiceContract interfaces are not exactly the same as the ones you define in your source assembly.
The only real difference is that the ServiceContract interface that Add Service Reference generates for SL has asynchronous operations defined (since SL doesn't support synchronous WCF calls). The rest of it (the XXXClient : ClientBase class) can be completely bypassed if you just use the ChannelFactory<TServiceContractInterface> directly.
I personally ended up sharing the synchronous ServiceContract interface, but creating a service contract with asynchronous operations using a System.Reflection.Emit.TypeBuilder. Then using a custom ChannelFactory, I created a wrapper around the dynamically generated asynchronous ServiceContract interface.
I hope that helps.
I have a set of webservices that I connect to using Silverlight Client. I use proxies generated by "Add service reference" or SLSVCUTIL.exe tool to connect to this service. So far, I have only used one single service. Now I want to use another service on the same server.
The problem is that, first service generated set of proxy classes for me, and second service will reuse the same set of classes (plus extra services/classes), e.g.
CustomerService.SaveCustomer(Customer customer);
OrderService.CheckCustomerLevel(Customer customer);
The problem is when I add reference to the second service, I can not reuse the same namespace for the second one (VS error), and when I use a different namespace, the generated classes, although are essentially the same, reside in different namespace, hence different and I end up with two Customer classes in two different namespaces.
Anyway around this? I just neeed to have two set of services, reusing the Customer class. I have already tried "reuse types in assembly / all assemblies" check mark when generating proxy classes, but it seems to have no effect.
any help is greatly appreciated.
I've run into this problem before, and the only solution I could come up with was to combine both web services into a single web service. This seems to be a limitation of the Add Service References/SLSvcUtil way of doing things.
If you're using Silverlight 4, you could conceivably try Silverlight/.NET assembly sharing to get around this (though I haven't tried it myself). In other words, compile the assembly that contains your data transfer objects in Silverlight, and then share it with the .NET/WCF back-end. That way, if you choose "Reuse types in assemblies", it would (in theory) actually re-use the existing Silverlight types for both service references.