I have been stuck on this for a few days and I would ping this community for answers before I give up.
*I would like to pass a delegate from a client application to a server application across app domains using remoting.
*The delegate is definition is in an Assembly which is shared between the server and client.
* The delegate it self is an anonymous delegate for which the body is declared on the client side.
My problem is that when I pass the delegate over to the server, the server requires the assembly for which the delegate body is declared(one of the client assembly). Our software architecture prohibits loading the client assembly. In my head when I think about it I should be be able to pass the IL which defines the delegate over to the server, create a delegate using dyanmicMethod and execute it. If that is the case then why does .net require the assembly even when the delegate body contains simple types? Is there a way to remote an assembly without requiring the assembly where the body is declared?
PS: the reason I want to do is for performance. The delegate encapsulates multiple calls to the server. I am unable to modify the server APIs etc to do this.
Thanks fro any information
I don't think you can do this.
When you pass the delegate to the server, the server will need to be able to load the definition of the class that defines the delegate, so there is no way to get a client-only anonymous method to execute on the server side.
There is a discussion on how to work around this at this link. I don't know if you can reorganize your code to align with that pattern.
It would be an intriguing idea to send some IL over to the other side and execute this in place, but I have no idea if that is possible. Sounds like there would be an awful lot of security and other barriers to cross to get this to work.
Related
When to use Channel Factory, and When to use Service Proxy in WCF?
My binding is NetNamedPipeBinding. and I'm planning to use a Duplex connection.
When to use a proxy?
We create proxy using svcutil.exe. The output of this tool gives a proxy class and makes corresponding changes to the application configuration file. If you have a service that you know is going to be used by several applications or is generic enough to be used in several places, you'll want to continue using the generated proxy classes. We use proxy in WCF to be able to share the service contract and entities with the client. Proxies have several restrictions like they need to have gets and sets , contructors can't be exposed , methods other than the service contract cannot be exposed, repetition of code, everytime that we add/modify a service contract/data contract/message contract we need to re-generate the proxy for the client.
When to use ChannelFactory
The other option is using the ChannelFactory class to construct a channel between the client and the service without the need of a proxy . In some cases, you may have a service that is tightly bound to the client application. In such a case, it makes sense to reference the Interface DLL directly and use ChannelFactory to call your methods using that. One significant advantage of the ChannelFactory route is that it gives you access to methods that wouldn't otherwise be available if you used svcutil.exe..
When to use a ChannelFactory vs Proxy class?
A DLL is helpful if the client code is under you control and you'd like to share more than just the service contract with the client -- such as some utility methods associated with entities and make the client & the service code more tightly bound. If you know that your entities will not change much and the client code is less, then a DLL would work better than a proxy. If the client to your service is external to the system, such as API, it makes sense to use a proxy, because it makes sharing the contract easier by giving a code file rather than a DLL.
In case of NetNamedPipeBinding
It's recommended to use ChannelFactory for the following two reasons:
The easy of use.
avoiding the proxy layer means extra performance.
Channel Factory and Service Proxy are equal features for getting one aim - consume you service. Usually if you control service contract interface both on you client and server, you'd better use ChannelFactory, because it is managed more easier. If you manage only client part - Proxy is a way to go, because othewise you would not be able to control the changes, made on the server side. Besides Proxy gives you a nice tool of generating async methods for your service :)
I am trying to figure out the best way to go about doing this: I am working on a project and I'm putting all my data access layer code into .ASMX files to keep them separated from my presentation layer. I am calling all my methods from the code behind and using the web services like class files. I am following this practice based on one other developer's work. Two opinions on this so far: One says when the code-behind calls the method from the web service, it's a performance hit because it has to go do an HTTP request and the other says, no performance hit. The ASMX files are within the same project on the same server. Is there indeed a performance hit or not really? I tend to think not.
Any help or opinion on this would be appreciated.
If you call as a web service, you still have to go through the proxy and argument marshalling even if you are calling within the same server; there is a performance hit compared to calling the same class directly; the call overhead may be orders of magnitude higher. You wouldn't want to do this if the called method isn't doing some substantial work.
I have a WCF service with a namespace called:
MyCompany.MyApplication.Configuration.ConfigurationHelperService
On the client side I have an assembly called which consumes this service:
MyCompany.MyApplication.Core (this is the default namespace)
When I add the service reference, the namespace I'm asked to specify in the Add Service Reference dialogue ends up getting tacked on the end of the client assembly namespace:
MyCompany.MyApplication.Core.MyCompany.MyApplication.Configuration
.ConfigurationHelperService
Because I'm asked for a namespace at this time it seems natural to specify the name of the remote service namespace. i.e. I'd like to refer to my remote service classes using their namespace MyCompany.MyApplication.Configuration.ConfigurationHelperService because they're technically not part of the client.
My questions are:
What's the rationale behind this, is this something to do with semantics?
Should I try to resist changing this behaviour by modifying the client side generated source to get the namespace I want?
I've lived with this for a long time (you have the same problem with ASMX web service clients) but have never seen a written down explanation why Visual Studio (and I guess svcutil.exe) works this way.
Well, I think you have two choices, really:
if you control both ends of the wire, e.g. you write the server and the client, you could put all the shared items like service contracts, data contracts etc. into a separate assembly and share that between client and server. That way, nothing would be duplicated, and both ends of the communication would refer to the exactly identical items in a given namespace of your choice
get used to the fact that if you add a WCF service reference in Visual Studio, you're basically getting a whole slew of duplication - because if you're not controlling both ends of the communication, that's really all WCF can go on - the metadata exchanged between service and client (through the WSDL or the MEX endpoint on the service). And since this clearly is part of the client, which is completely separate from the service (all they share, typically, are the wire-formats defined in the XML schema - nothing else), its namespace will also be client-oriented. I think this is a (good) feature, and not something I'd try to combat.....
By default, in a SOA world using WCF, the client and the service are totally independant of one another. There's no "remote object" connection or anything like that between the two: the client proxy has a method call happen, bundles up those parameters passed in plus some information what method on the server to call, and serializes it all up into a serialized message (read: a text / XML message, basically). That message is sent across the wire to the server which then handles that message and returns a response.
So this is not just a .NET function call or something - those two pieces of your system are (by default) absolutely independent of one another. Considering that, to me at least, it makes sense that everything the client does will be placed in the client's namespaces - after all, the server could be something totally different, like Java, PHP, a IBM mainframe - you typically don't have any clue what it is (and don't need to).
I have an ATL C++ in-proc COM component. This component is not for external use - I only need it for use in our application.
Once in a while users put it into COM+ and this leads to all sorts of weird errors - "Access denied", etc which I'd like to just never hear about. The best way would be to do something that would prohibit putting the component into COM+ so that it can only be used as an in-proc server. Is there a way to do this?
Do you implement only your own interfaces? If so, you should be able to mark them "[local]" in the IDL, and then strip the module of all marshalling information (type library, P/S), etc.
If there's no basis for marshalling available, COM+ shouldn't be able to register the module. COM+'s mechanism for interception relies on forcing objects into a remote context and getting in between the proxy and stub and their corresponding parties. So, if you remove every opportunity for marshalling, it shouldn't be able to intercept your interface methods.
Prevent registering your module is finalized and then use your DLL as described in this article Creating COM objects directly from the dll.
I have a C# module responsible for acquiring the list of network adapters that are "connected to the internet" on a windows Vista machine. The module uses the "Network List Manager API" (or NLM API) to iterate over all network connections and returns all those for which the IsConnectedToInternet value is true.
I received some suggestions for the implementation of this module in this SO question
To test this module I've decided to write a helper that returns the list of internet connected interfaces based on another logic, so it would be a sort of a "reality check" for the original module's logic. Note that for the test helper I am willing to use detection methods that might be considered bad practice for production code (e.g. relying on some internet resource like "Google" to be available - in case it shuts down, blocked by our internal firewall etc. it's relatively easy to fix the test as opposed to a deployed product base).
The alternative detection method I chose was to try to connect to "www.google.com:80" with a TcpClient. My problem: When I have more than one connected adapter (e.g. both wireless and LAN) the detection method fails for one of them with the error "A connect request was made on an already-connected socket".
My question is three fold:
How would you go about testing such a module in general? Do you support the idea of doing the same thing in a different way and comparing the results or is it an overkill and I should rely on the system's API? My main problem here, is that it's very hard to pre-configure the system so that I'll know what the expected results are in advance.
What alternative logic would you suggest? One thing that was suggested in the aforementioned question was looking at the routing table - what about considering each adapter that has a routing entry with a destination of 0.0.0.0 as "connected to the internet"? Other suggestions?
Do you understand why I get the "already-connected" error with the current test logic?
I can only answer your question about the unit test.
The code you're testing is, in your own words, "a C# module responsible for acquiring the list of network adapters that are 'connected to the internet' on a windows Vista machine. The module uses the 'Network List Manager API' (or NLM API) to iterate over all network connections and returns all those for which the IsConnectedToInternet value is true."
If I were writing this module, I would first use an interface for the NLM API, call it...NLMAPIService. Now, for the real code, create an Adapter that implements NLMAPIService and adapts the real NLM API.
For testing, create a class FakeNLMAPI that implements NLMAPIService and has all of its data in-memory somewhere, or in an XML file, or whatever. Your module calls methods only on the NLMAPIService, so you don't have to change any "real" code depending on whether you're testing or not.
Therefore, in your test setup method, you can instantiate FakeNLMAPI and pass it to your module, and in production, instantiate your NLM API Adapter.
I'm going to assume that you can instantiate and modify the object that represents a network connection. If not, you can follow the same pattern for faking the actual network connection object.
Dependency Injection is a very handy pattern to deal with issues like this. Instead of simply using the NLM API components directly in your code define an interface and a class that implements it and serves as a proxy to the NLM API. Pass an instance of this class to your module in the constructor and have your module use it. In your unit tests, instead of the real proxy object, use a mock object that returns known information -- it doesn't even have to reference the NLM API -- to use in testing the logic of your module. Granted, your proxy class will need some testing as well, but the logic in it is much simpler -- probably just some data marshaling. You might be able to convince yourself of its correctness or, if not, do some manual testing on it to make sure that it is working properly.
UnitTests shouldn't access to external resources. To UnitTest your method, I would stub out the Network List Manager API.
You still need an acceptance test layer. In that test environment you should replicate various configurations you expect to support in your environment, setup your own webhosts, routers, machine config. Acceptance testing should be done at the user experience level using a tool like Fitnesse.