+ Start a Discussion
tyshocktyshock 

Newbie needs help: unable to generate a serializer......

Hi,

I am trying a proof of concept to show that our dotnet based webapp can access/change info in our salesforce environment.  I am working on a simple example to get everything working.

I modified the basic c# 'quickstart' code to change the name of a salesforce 'opportunity'.  I also made a simple console app as a driver to this class.  I can compile and successfully run the consoleApp&assembly on different machines.   So far so good.

My next test was to try to integrate the assembly into our proprietary dotNet based web application.  I added a method to the 'quickstart' class (the class is now renamed PartnerOpportunityRegister)  called testObject() which returns a string ("success").  I can instantiate the class and successfully call this method, so I know the assembly is being loaded/referenced correctly from within our webapp.  However, when I try to access any methods which use sforce objects, I get the following errors:

2004.10.19 15:16:15: failed in doLogin():

Unable to generate a serializer for type PartnerOpportunity.sforce.SetPasswordResult from assembly because the assembly may be dynamic. Save the assembly and load it from disk to use it with XmlSerialization.
  
at System.Xml.Serialization.Compiler.AddImport(Type type)
   at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings)
   at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings)
   at System.Web.Services.Protocols.SoapClientType..ctor(Type type)
   at System.Web.Services.Protocols.SoapHttpClientProtocol..ctor()
   at PartnerOpportunity.sforce.SforceService..ctor()
   at PartnerOpportunity.PartnerOpportunityRegister.doLogin()

What does this mean?  I am quite new to dotNet, so I may be ignorant to the obvious here.  Thanks in advance to any responses.

 

 

 

 

SuperfellSuperfell
I've never seen that particular error before, but there is one gotcha with using a .NET web services client from ASP.NET, and that is that the ASP.NET user doesn't have access rights to the directory where the web services code is trying to write the temporary assembly to. I can't remember right now what that directory is, but i think its \windows\temp.
tyshocktyshock
As a followup, I got with the support team for our webapp and they suggested I add the assembly to the gac on the server and try it.  Sure enough it worked flawlessly.  I don't know what difference that would make, but it did something.