Please can someone provide a situation where the ReferencedAssembly property is not null, I assume that this corresponds to ResourceLocation.ContainedInAnotherAssembly.
Thanks
Tony
ReferencedAssembly will be non null if a resource name is passed to GetManifestResourceInfo that is not the name of a resource embedded in or linked to the assembly and the AppDomain ResourceResolve event has been handled and returns an Assembly that does contain a resource by that name.
The ResourceResolve event will also be raised when using the ResourceManager with satellite assemblies and using the GetString, GetObject and GetStream methods even if the satellite assembly for the provided culture exists in a correct location.
Related
DllRegisterServer is called, when Windows or OLE wants me to register my classes under HKEY_CLASSES_ROOT\CLSID. But I don't understand why this function has to be implemented, because when Windows/OLE can make calls to my DLL, then my classes are already registered with their CLSIDs and their path to the correct DLL. Can somebody tell me, what I am misunderstanding?
You are confounding the chicken and the egg. In order for COM to help a client app to create objects and marshal calls, it needs to know where your COM server is located. The client app just uses a number, a GUID, to tell COM what object it needs. The mapping from a GUID to code in an executable file requires COM to know where that file is located first. And, if necessary, how to marshal a call on an interface from one apartment to another.
It is registering the server that provides COM with that knowledge. It writes keys in the registry that COM uses to find the file back. Like the CLSID key, its InProcServer32 sub-key provides the path to the file. Etcetera. Or the manifest embedded in the client app if it chooses to use reg-free COM.
Observing this with SysInternals' Process Monitor can provide a lot of insight. You'll see what DllRegisterServer() does and how a client app uses those keys.
For the peoples wondering about Title of Question
Example of COM object is Dynamic Context Menu ( which would be a DLL)
to register it-
First Make a Random GUID under HKEY_CLASSES_ROOT
Under That GUID make key named "InProcServer32"
set value of this key as full path of your DLL
This is called Manual Registration
people's with no knowledge of registry editing should also be able to register your dll too.
for that, you should write codes to make these GUIDS and InprocServer32 keys etc programatically Under the DLLRegisterServer() Function in your DLL
so that , people with no knoledge of registry editing will be able to type -
regsvr32.exe "full path of your DLL"
in command prompt for registring your DLL
when they type that command, regsvr32.exe will do nothing but call that DLLRegisterServer() in your DLL
and by calling this function, codes of writing registry keys such as making random GUID and InprocServer32 keys will be Executed ( which you have written )
so registry entries will be made and that is called Registration.
so , according to me regsvr32.exe was just created for the people who have less knowledge of how to edit registry.
How can I remove specific types from the the generated WSDL document of a WCF service?
I already have a System.Web.Services.Description.ServiceDescription for my service in a custom IWsdlExportExtension. Where can I find the types in the service description?
Thanks
When you're creating your .NET proxy class using the svcutil command line utility, you can define a command-line switch
/excludeType:<type>
Specifies a fully-qualified or assembly-qualified type name
to be excluded from referenced contract types.
When using this switch together with /r from separate DLLs,
the full name of the XSD class is referenced.
Short Form: /et
See the complete and freely available MSDN documentation for svcutil for more details.
I have adapted the WCF 'Stream' sample application that is provided by Microsoft to use a Request object that is set up in a Shared Assembly and decorated with the MessageContract attributes. This should then be passed in to the UploadStreamRequest() method of the service.
The problem is that when I add a service reference to the client and try to call the method, each of the properties of the MessageContract object have just been converted to separate parameters.
I have also experimented with the 'Always generate message contracts' option within advanced settings, and although this then changes the method so that it is passed a request object, it has regenerated its own proxy representation of the object (even though I have 'Reuse types in all referenced assemblies' ticked).
Can anybody explain what I am missing here?
Many thanks
I had this problem and I have fixed it ticking the checkbox "Always generate message contracts." when I add the Service Reference.
Hope this helps.
I have a WCF Service which returns some custom objects to a desktop client application. Both projects share the same ObjectLibrary.dll, however when the WCF server return these objects it is returning
ClientApplication.ServerReference.ObjectType
instead of
ObjectLibrary.ObjectType
Is there a way to get the WCF server to return the ObjectLibrary's class type?
When you configure the service reference, set the "Reuse types in referenced assemblies" checkbox, and ensure that either the "Reuse types in all referenced assemblies" radio button is checked, or else "Reuse types in specified referenced assemblies" is checked instead, and that all the shared assemblies have check marks next to them in the list below.
My mistake was that I was trying to reference the Service from the ObjectLibrary, and the Service contained a reference to the ObjectLibrary so it was creating a circular reference. I changed my solution so I had one project for object base classes, one for the service which referenced the base classes, and then defined the object methods in a third project which referenced the server and the base class dlls.
I am invoking a service through WCF and has encountered a problem with non-matching namespaces.
The object that is beeing sent though the service is in the namespace MyProject.Commons.BuisnessObjects, and I have verified this through WcfTestClient.
When I invoke a method clientside on the service (after initiated this with new MyServiceClient()), the method give me the correct objects, but with different namespaces.
The object is now of Web.MyService.Object. I have tried casting, but that didn't help.
Anyone who has seen this before?
Thanks, Tine
This is the expected behavior. It's how Web Services work. They are meant to be different types.
If you have added a service reference (i.e. WCF) rather than an old fashioned web reference, then you can match these up. Add a reference to the shared library defining your object type to the client before you add the service reference, then there is an option when you add the reference to re-use types.
This is because your types are not shared across service and client. Therefore the client does recreate for you your datastructures, in the Web.MyService namespace.
To avoid this you should share your data structure types between client and service by referencing your assembly containing your type BEFORE adding the service reference
You can find the detailed scenario and sample project there:
http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html