I have a custom C# component library (D1) that has a web reference, D1 is referenced by in library (D2) that makes call to methods in the web reference. D2 is loaded into a console application using reflection.
When I reference D1 above, in a test console application and make calls to the methods in the web reference. However, when I load it using reflection and make those same calls, receive the the following error: cannot call because it is a web method"
I have tried this using the .NET 2.0 and 3.0 framework.
Any thoughts?
I got the same error when I was checking value in the debugger. I'm not sure how comparable that is to your reflection call.
My code called it just fine but the debugger threw this error.
Hopefully that may help someone
It would be good practice for the class exposing the [WebMethod] tagged API to be a thin shim over the real implementation -- it is possible that the calls you see working are bypassing such a shim.
What does Reflector have to say about the assembly?
Related
I'm working with one application that that has and C# API. This program has different versions of it. But the api stays the same through its versions.
So i have written a managed code to one of its versions, and now i want to run the same code at different version of the application at runtime where i exactly know witch version of the app is running.
Question is:
Is it possible to replace assembly version and dll location at run time without writing unmanaged code using reflections?
Yes, you can use Assembly.LoadFrom to load an assembly. You can then use reflection to go thru the types of said assembly and call methods.
To avoid needing to use reflection for everything there should be a shared interface-assembly that define your api. There should also be a single entry point to the API. So you can use reflection find the class that implements the entry-interface, create an instance of this class and cast it to the interface. That lets the rest of the code use actual types.
You still need to be careful however, if there is any miss match between the interface and the actual types, you will get an runtime exception. You will not get an exception when the interface method is called (as might be expected), but when the method that calls the interface method is called. This due to the jitter resolving types when a method is compiled, and this is done the first time it is called.
For example:
There is API a.1 in DLL A and API B.1 in DLL B.
API A.1 calls API B.1.
Is there an open source tool or method to know this call path(A.1->B.1)?
.Net assemblies contain a list of referenced assemblies. This can be inspected by tools like IL SPy.
There is no easy way to check if a specific method on one assembly may calls another assembly. You could perhaps inspect the CIL code for this, but it will require a bit more work.
There is also native dependencies, these are not listed in the same way, and use another method to load.
I've created a .NET Profiling DLL that implements the ICorProfilerCallback3 interface.
I'm using the profiling to trace the functions called during Runtime, however, I'm looking to trace application specific functions, not the standard .NET framework functions.
I successfully used the SetEnterLeaveFunctionHook method and supply it with callback functions.
Then while I'm in the callback functions, I get the function information and assembly information using the GetFunctionInfo and GetModuleInfo2 functions.
The issue I'm running into is this obviously gets called for EVERY function and I'm looking for a way to distinguish between a .Net framework DLL and not a standard DLL.
For instance the majority of calls when the application starts goes to the mscorlib.dll which I'm not interested in tracing.
Any thoughts or ideas? I've tried call this function but pdwImplFlags doesn't appear to populate with anything useful.
https://learn.microsoft.com/en-us/dotnet/framework/unmanaged-api/metadata/imetadataimport-getmethodprops-method
You can use SetFunctionIDMapper2 to specify a mapper which checks to see if the function is of interest and return false in pbHookFunction if it's not. Then you should only get callbacks for the methods where you returned true in pbHookFunction.
I have a query regarding dotnet framework.
Suppose I have a class library DLL for my clients, which have set of methods. For some reason, I have removed some methods, and deliver it to my client. How I could ensure that my client will not get any error in their code because of removed of methods as they are using it.
If you remove the methods they will certainly get an error so marking them as obsolete would be the best solution to go. You will break compatibility between the code using different versions of your DLL which is quite bad and unpleasant for clients.
Does anyone know if its possible and if so, what the syntax is for calling a service operation via linqpad?
Also, can I used named parameters when I call it using linqpad- how? That would be great b/c I have a lot of parameters in the service operation and I don't want to have to specify each one.
Thanks!
Unfortunately, this is not possible: LINQPad relies on the .NET WCF client and EntityClassGenerator in System.Data.Services.Design.dll, which don't really support service operations (as of Framework 4.0).
The workaround at this stage is the same as what you'd do if you were coding in Visual Studio and is described well here.
Hence you could type the following into LINQPad to call the operation GetContacts(string firstName):
this.Execute<Contact> (new Uri ("GetContacts?firstName='John'", UriKind.Relative))
or, if the service returns a sequence of objects:
CreateQuery<Contact>("GetContacts").AddQueryOption("firstName", "'John'")