I have 3 projects in my solution.
A common class library named ReportBuilderLib
A WPF application named ReportClient that contains a service reference to a 3rd project -
A WCF web service which contains web methods for my application to call upon.
Initially when setting up both the service and the application i added the common library to references on both projects so that i could use the classes i needed to in both.
It quickly cam clear that in the process of generating the code to use the web methods in my client application, it was automatically importing certain namespaces that i had used in service application.
This was throwing me conflicting reference warnings as they were effectively being imported from two separate resources.
I then removed the reference to the library in my report client, i could see that VS was only importing one out of the two namespaces my client requires. Both of which are returned by methods in my ServiceContract!
Having looked at the generated code for the client, it seems to be re-creating the classes i have included in the library and providing only the public properties for access.
Is it possible to use librarys like i am trying to with WCF. Or should i scrap the common library idea and simply create some data transfer classes on the service end?
You should be able to reference the common library on both ends, but it may be useful and less of a headache to implement data transfer classes like you suggested. Using special classes (or serialization like JSON) to send and receive data from the service would make it easier for you to re-use the service for multiple client projects.
Any time you decrease the coupling between layers of an application you make it easier to implement changes/upgrades in the future :)
Related
We are transitioning a WCF based solution over to use gRPC.
We require both the Service and Client code generation that the Grpc.Tools package provides. However, we need the Clients to target .NET Standard 2.0 for comparability reasons.
Services need to call other services, so those projects need to be able to consume both the service stubs and the client stubs.
We also don't really want the service stubs to be exposed to consumers just wanting to use the gRPC clients.
This is proving a challenging requirement to satisfy.
Trial 1:
Have two projects, both importing the same proto files, each set to generate either the Server or Client.
Problem: A consuming project can't reference both server and client project due to the generated messages having duplicate namespaces.
The C# namespace is defined in the proto file itself.
Trial 2:
Separate the proto files out into messages and services. Have a models project which only generates the messages into code.
Have the client and service projects reference the models project, and import the services proto files to have them generate the stubs they need.
Problem: gRPC generates the stubs inside of a static class, which again has the same namespace in both projects so a consumer is unable to determine which version to use.
I now have two routes I can go down.
Option A:
In both the client and server projects, create classes which inherit from the gRPC generated ones so they can be exposed onto a different namespace.
For the services, this isn't so bad. The clients however have two constructors and a instance generation method which would need to be brought over to the child class.
Option B:
Create duplicate proto files for the service definitions, one having a namespace for the service stub and the other having the namespace for the client stub.
Both options have their downsides. Option A is probably the least bad as it doesn't require two files to be manually kept in sync.
Does anyone have any alternative recommendations?
Ideally there would be a way to alter the namespace defined in the proto files somehow when using Grpc.Tools, but reading the documentation, there doesn't seem to be a way to do that.
I am developing an API for controlling a printer-like device remotely over network. The client-part of the API will be given to our customer, so that he can integrate it into his process-control software.
I am using WCF for this task and need to pass data between the server-DLL and the client-DLL. With my current implementation/setup I am forced to put the corresponding types into a separate library to avoid a circular dependency between projects.
Since I am completely new to API design, my question is now:
Is it acceptable (e.g. in line with "best practices") to put types that the client-DLL uses (i.e. its dependencies) into a separate DLL, so that the consumer of our API needs to reference two DLLs?
If so, I would then also added the interface for my client in that DLL, to facilitate unit-testing. Do you see any issue with that?
I am trying to improve the speed of a C# job, let's call it 'WidgetProcessor'. In one run, WidgetProcessor will process about 5,000 widgets and take about 12 hours to complete (about 8 seconds/widget).
WidgetProcessor makes references to 3 different web services and calls them multiple times for each widget processed. There are various performance/design improvements that can be made to the 'WidgetProcessor' program, but I want to test if the multiple web service calls over the network cause the job to run slow.
I have the source code for each of the three web services (and have access to all of the resources those web services use), and I'm wondering if there is a way to easily use the web service interfaces in WidgetProcessor by referencing the web service projects themselves (instead of calling the web service over the network). The web services are implemented in C#.
I would reference the service implementation classes directly, but the main problem I'm running into is that the web services have collectively about 100 data contracts and the public facing names are different than the implementation classes.
[DataContract(Name = "WidgetInfo")]
public class WidgetDataContract
{
// DataMembers
}
Thus, referencing implementations directly means I'd be making many code changes in WidgetProcessor. Rather, I'd like to use the service interfaces, so that code changes can stay at a minimum.
Basically, I want a service in my WidgetProcessor solution that looks and acts like a web service, but doesn't perform its operations over the network.
Is this even possible?
You can add adapter classes which subclass the implementation with the name specified in the datacontract:
public class WidgetInfo : WidgetDataContract { }
If you are finding the overhead of the service call to be overly expensive, you may see benefit of going to a different binding or serialization format. WCF can approach in-process speed when tuned properly.
Edit: If you are intent on not modifying any code, you do have a couple options, but I think they are solutions in search of a problem:
Mono.Cecil or Roslyn to automatically map between the classes pre- or post-build
For only the types, you could use TypeForwardedToAttribute, but property access is problematic. This may be dependent upon placing the svcutil generated classes in another assembly.
Use Castle to build dynamic proxies and map access based off of attributes
I create a lot of object classes when I do programming. There are many situations where same object definition will be reused across multiple projects. In windows, I simply build them into .dll file library and include them as the project reference. Therefore, when I need to add additional properties or methods, I just need to do it once and I don't need to worry about go through all projects and manually update the object class definition.
Now, I'm given a project to build an Android application which requires several object classes that's being used within other projects (and must be synced). Of course, I can manually create them within Android and update them every time whenever there's a change, but this is very dangerous because one day in the future, it is very likely to be out-of-synced.
Anyone have suggestions on how to share class library across C# and Android?
Thank you
The only way I know how to do this is to use Xamarin which would allow you to write your entire Android application in C#.
The problem is Android and .Net use completely different runtimes that are not compatible.
I don't have a clear enough view of what your application does, but if you are using the C# objects on a webAPI and looking to keep your objects synced with the client app, you can use Breeze.js - this keeps your client/server biz objects synced. The classes get pulled in dynamically via a meta service call.
I need to create a project for multiple web services using WCF in c#. The web services will be calling other assemblies to perform the core processing. The assemblies will be accessing data from SQL Server. One of the parameters that will be part of every web service method will include the database to use. My problem is how to pass the database parameter to assemblies to use. I can't change all the signatures for all the satellite assemblies to use. I want to reference some kind of variable that the satellite assembles reference. Theses same satellite assemblies are used with a Windows Forms app and an ASP.NET app so I would need to have something that all types of applications could use. Static fields are not good since for one web service call the database could be "X" and for another it would be "Y". Any ideas?
This is the sort of thing that might play nicely with an IoC or DI framework - having some interface that includes the database information, and have it pushed into all the callers for you. Even without IoC, hiding the implementation in an interface sounds like a solid plan.
With your static concept; a [ThreadStatic] might work but is a little hacky (and you need to be religious about cleaning the data between callers), or another option is to squirrel some information away on the Principal, as this is relatively easily configured from both WCF (per-call) and winforms (typically per-process). In either case, be careful about any thread-switching (async, etc). In particular, note that ASP.NET can change threads in the middle of a single page pipeline.