The problem isn't really something that can be "fixed" - Microsoft took away
programmatic access to their WSDL tools and makes users call their command
line tools, so the gateway tries to do some things for you, but you should
really try to create web service proxies yourself.
I believe your particular issue is that the flashgateway.dll can't either
execute wsdl.exe, write the resulting web services proxy C# file
SomeWebService.cs file to disk, or execute csc.exe to compile the
SomeWebService.cs file into a SomeWebService.dll in the LAC.
Perhaps you don't have the Framework SDK installed in the default location
or perhaps you don't have wsdl.exe and csc.exe in your system environment
PATH? Perhaps you need to give the ASP.NET user write permissions to the
/bin subdirectory (the Local Assembly Cache (LAC)) or... which I suggest you
try this way in future... manually creating the web service proxy yourself.
You use the Microsoft.NET Framework SDK tool "wsdl.exe" to create a C# stub
class to act as a proxy to handle calls from the gateway to the webservice.
But, of course, since this generated proxy is just C# source - it has to be
compiled into an assembly. For this, you use good ol' csc.exe and output the
compiled code as a library.
Note: that the service name is not picked based on the WSDL URL. It comes
from inside the WSDL format - specifically the "service" name definition -
which for .asmx files is usually towards the end of the file.
Here's an example of the command line args required to generate a proxy
assembly:
wsdl.exe "nologo /o:SomeWebService.cs
http://somewhere.com/something/somethingelse.asmx?wsdl csc.exe /out:SomeWebService.dll /t:library SomeWebService.cs
This assembly would go next to the flashgateway.dll in your LAC.