We moved to .net 4 and the work with exchange doesnt work anymore.
I'm using interop.cdo dll and when doing sessionclass I'm getting an exception -
retrieving the com class factory for component with CLSID faile due to the following error: class not registered.
Is there a way to fix this with this dll or should I replace all the work with exchange?
If I do - what is the best way? I cant seem to find information about it.
Thanks
Related
I have a WCF service, called A which implements IA. This server uses some classes that are defined in a common class (in a common dll referenced by the A service dll). I have another WCF service, called B which implements IB.
Now, A and B have service reference to each other. This worked fine. But now, when I try to update IB I have a problem. I get a custom tool error failing to generate the code for the service reference. Unchecking the “Reuse types in referenced assemblies” solves this issue, but then I have to cast each type to itself (actually).
I created a separate project, in A solution, that has reference to B service. Now, I am able to add service reference, but I get ambiguous error for all types that are defined in the common dll. Any idea how to solve this issue?
How can i solve the next problem that i have. Im using WCF and it reference a COM.
Creating an instance of the COM component with CLSID {...} from the IClassFactory failed due to the following error: fffffdf8f Exception from HRESULT:0XFFFFFDF8F
Obviously the CLSID that appears is my COM. My COM is compiled in Power Builder 11.5.
It appears in production environment after a long time of using but at the beginning of the day it work perfectly.
Do you think I should use System.Runtime.InteropServices.Marshal.FinalReleaseComObject(COM)?
I have a Silverlight 5 app. This app has been in development for 18 months. This app calls back to a WCF service. I just had a support request.
Before today, the service would return ObservableCollection<T> results. However, now all of the sudden, out-of-the-middle of nowhere, it starts returning T[] results after I updated the service reference in the Silverlight app.
My question is, what could have happened that would cause this change? This has caused approximately 70 errors due to type conflicts. Am I overlooking a basic setting?
Thank you!
If you're using a service reference to communicate with the service, make sure the Data Type hasn't been changed. Right click on the service in the Service References folder, select Configure Service Reference..., and look at the Data Type - Collection type:. If it's System.Array, then this may be your problem. Change it to ObservableCollection and see if that helps.
I'm trying to consume a WCF 4.0 service in my application. I built, tested, and deployed the service from the ground up. The service works in the WCF test client and can be consumed in any other test project I built. The problem is this one particular application... the only one that matters as it's the reason I built the service.
When I build the application after referencing the service I get an error. The error is "The type name 'AAA' does not exist in the type 'YYY.YYY' ".
The project consuming the service is named 'YYY.Web' and is in the 'YYY' namespace.
The service was initially created in the 'YYY.ReportingService' namespace. It has been changed to a different namespace once this problem started. Is now in the 'MMM' namespace.
I added a using directive 'YYY.Service1'. I also tried aliasing the using directive (using test = YYY.Service1)
To make sure something wasn't messed up with my service and its namespaces, I built a new service with a single method. It takes a string parameter and returns "Hello, " and whatever string is passed. This services also works in the WCF test client and the couple of test projects I created. This service is in the SimpleTestService namespace, BasicService class, with a methiod named GetGreeting. Naming was done intentionally to avoid any possible naming collisions. The error still occurs with this new service.
Any thoughts on this? Thanks!
This one took me a while. Turned out, that "The type name 'AAA' does not exist in the type 'YYY.YYY' " was caused by the YYY.YYY - my consuming class sharing name with its containing namespace.
Solution: rename the consuming class to something that is not equal to the full name of its namespace, i.e. YYY.XXX.
I realize it's and old question, but I just had this problem and the issue was a namespace conflict.
In my case AAA was named ServiceClient and that generated the same error you experienced. Once I removed the namespace conflict (called it ConsoleClient instead) all worked as expected.
I have another issue. Imagine two projects with different namespaces and following classes
Project 1
[DataContract(Namespace="SomeNamespace")]
public class A
{
[DataMember]
public class B { get; set; }
}
Project 2
// Here no DataContract attribute
public class B
{
//...
}
In this case you'll get same error as above. Hopefully this will help someone.
Do you have an old version of the service DLL in the GAC? Your application might be referencing another version of the assembly hence the missing types.
I hope you have updated the service reference after renaming the namespace in the service. Usually you get this error when the client side proxy is not updated with the latest types form the server. You can try updating the service reference.
I have references to two different WCF services in a project. I updated the reference for one of the services, and now no code is generated for it. The references.cs file just has the "this is genrated code" comment at the top. Updating that same service in other projects and updating the other service both work fine. It's only that one service reference in this one project that's causing the problem, and I'm getting no information from Visual Studio (it just says it failed to generate code and I should look at the other errors, which provide no information).
If I uncheck the "reuse types in referenced assemblies", code is generated, but I don't want to have this one project be different from the others. I'd like to solve the problem. Re-checking the reuse type option produces an empty references.cs file, again. The collection type doesn't seem to matter, either.
How can I diagnose and solve this problem?
Update:
It seems I was mistaken. Updating the service reference does seem to break the generation in other projects as well. I did also notice these warnings, as well:
Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: ISerializable type with data contract name 'Exception' in namespace 'http://schemas.datacontract.org/2004/07/System' cannot be imported. The data contract namespace cannot be customized for ISerializable types and the generated namespace 'TheDefaultNamespaceOfTheProject.ServiceReferenceName' does not match the required CLR namespace 'System'. Check if the required namespace has been mapped to a different data contract namespace and consider mapping it explicitly using the namespaces collection.
Obviously I changed the namespace there, but it seems like it's trying to map System.Exception to ThatNamespace.Exception? Why would it do that, and how can I correct it? I think this is the key to the whole thing.
I had a similar error in a Silverlight application making WCF calls. I created a WCF method that passed an Exception object as a parameter. It turns out that Exception objects are not serializable in Silverlight because:
http://blogs.msdn.com/b/suwatch/archive/2009/01/21/wcf-silverlight-exception-and-serialization.aspx
Here's the relevant excerpt:
WCF’s DataContractSerializer serialize s Exception class via
ISerializable (Exception in .Net Framework implements ISerializable).
However, in Silverlight, there is no ISerializable interface.
Therefore, Serialization information of Exception transferred over the
wire will not be set into the Exception class. This does not only
apply to Exception but also any types implementing ISerializable on
the .Net Framework serialized to Silverlight.