Webservice stub class not compiling

[Nick Gilbert]

Hi,

I'm having problems using Flash Remoting with Web Services for ASP.NET
and I've narrowed the problem down to csc.exe when it tries to compile
the stub class.

Flash Remoting (flashgateway.d ll) is calling the following command line
to compile the stub class:

"csc.exe" /out:ExampleWebS ervice.dll /t:library ExampleWebServi ce.cs

If I run that command manually, it correctly generates the DLL and the
application works, so why can't it generate the DLL file when it
compiles it automatically? What's the difference between me running it
from the command line and Flash running it as the ASPNET user?

We then did some more research and have found that csc.exe is producing
the following error while trying to compile the file:

fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too
long or invalid

I've searched for this error everywhere and I can't see that anyone else
has ever encountered it. I've even tried reinstalling .NET in case my
installation was messed up. Where is csc.exe getting the above string
from? (ie where do I look to fix it, and what should it be?)

I can't work out what this error means. I expect it relates to the
extraneous characters on the front of the path but I don't know why
that's happening or why those characters are there.

Do you know how I can fix this problem?

Thanks,

Nick...

[Dino Chiesa [Microsoft]]

who is flash remoting?
is this a macromedia thing?
maybe you should be checking with them?

-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Ox******** ******@TK2MSFTN GP12.phx.gbl...

Hi,

I'm having problems using Flash Remoting with Web Services for ASP.NET and
I've narrowed the problem down to csc.exe when it tries to compile the
stub class.

Flash Remoting (flashgateway.d ll) is calling the following command line to
compile the stub class:

"csc.exe" /out:ExampleWebS ervice.dll /t:library ExampleWebServi ce.cs

If I run that command manually, it correctly generates the DLL and the
application works, so why can't it generate the DLL file when it compiles
it automatically? What's the difference between me running it from the
command line and Flash running it as the ASPNET user?

We then did some more research and have found that csc.exe is producing
the following error while trying to compile the file:

fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too long
or invalid

I've searched for this error everywhere and I can't see that anyone else
has ever encountered it. I've even tried reinstalling .NET in case my
installation was messed up. Where is csc.exe getting the above string
from? (ie where do I look to fix it, and what should it be?)

I can't work out what this error means. I expect it relates to the
extraneous characters on the front of the path but I don't know why that's
happening or why those characters are there.

Do you know how I can fix this problem?

Thanks,

Nick...

[Nick Gilbert]

> who is flash remoting?

is this a macromedia thing?
maybe you should be checking with them?
It is a macromedia thing, but the problem is with the csc compiler as
you can see from the error message. We have reproduced the problem
completely independanty of any of the Macromedia products using the
following code:

private void Page_Load(objec t sender, System.EventArg s e)
{
string text2 = @"C:\Inetpub\ww wroot\flashremo ting\bin";
string text4 = @"ExampleWebSer vice";
Process process2 = new Process();
process2.StartI nfo.WorkingDire ctory = text2;
// process2.StartI nfo.FileName =
@"C:\WINDOWS\Mi crosoft.NET\Fra mework\v1.1.432 2\csc.exe";
// With the line below in place, it executes correctly,
// but the line below causes it to fail!
process2.StartI nfo.FileName = "csc.exe";
process2.StartI nfo.CreateNoWin dow = false;
process2.StartI nfo.UseShellExe cute = false;
process2.StartI nfo.ErrorDialog = true;
process2.StartI nfo.RedirectSta ndardOutput = true;
string[] textArray1 = new string[5] { "/out:", text4, ".dll /t:library
", text4, ".cs" } ;
process2.StartI nfo.Arguments = string.Concat(t extArray1);
process2.Start( );
string stderr = process2.Standa rdOutput.ReadTo End();
process2.WaitFo rExit(30000);
Trace.Write("ex it code", process2.ExitCo de.ToString());
Trace.Write("st dout",stderr);
}

You can try this yourself.. just provide it with a basic CS file for it
to compile in the BIN folder called "ExampleWebServ ice.cs" which can
probably contain any code.

On my machine this will cause the following error to appear in the Trace
output:
fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too
long or invalid

So this problem is not actually related to Macromedia products in any
way - I probably shouldn't have mentionned it - it's simply what I was
working with when I noticed this problem.

Any ideas why this is happening? I'm not sure what the .rsp file is for,
but it's obviously getting an invalid path from the environment or
configuration file somewhere. Note from the comment that if you provice
the full path to the csc.exe file in the code, then it works fine (I
can't actually use that as a solution as the code above is not my code
and was obtained using Reflector).

Thanks,

Nick...

Dino Chiesa [Microsoft] wrote: who is flash remoting?
is this a macromedia thing?
maybe you should be checking with them?

-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Ox******** ******@TK2MSFTN GP12.phx.gbl...

Hi,

I'm having problems using Flash Remoting with Web Services for ASP.NET and
I've narrowed the problem down to csc.exe when it tries to compile the
stub class.

Flash Remoting (flashgateway.d ll) is calling the following command line to
compile the stub class:

"csc.exe" /out:ExampleWebS ervice.dll /t:library ExampleWebServi ce.cs

If I run that command manually, it correctly generates the DLL and the
application works, so why can't it generate the DLL file when it compiles
it automatically? What's the difference between me running it from the
command line and Flash running it as the ASPNET user?

We then did some more research and have found that csc.exe is producing
the following error while trying to compile the file:

fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too long
or invalid

I've searched for this error everywhere and I can't see that anyone else
has ever encountered it. I've even tried reinstalling .NET in case my
installation was messed up. Where is csc.exe getting the above string
from? (ie where do I look to fix it, and what should it be?)

I can't work out what this error means. I expect it relates to the
extraneous characters on the front of the path but I don't know why that's
happening or why those characters are there.

Do you know how I can fix this problem?

Thanks,

Nick...

[Dino Chiesa [Microsoft]]

if I understand you properly, then
- the problem is that csc.exe is returning something strange
- it happens only when CSC is run from an ASPX page
- if you specify the fully-qualified path for CSC then no problem

Seems like you have a good workaround?

Another workaround is to specify the /noconfig option to csc.exe.
http://msdn.microsoft.com/library/en...noreCscrsp.asp

The csc.rsp string you see is not a made-up name - it is the default
"response file" for the csc command. (what is a response file? If you run
csc.exe @foo.rsp , then CSC will process options from the given rsp file,
known as a response file. ) It is using a kind-of strange UNC path syntax,
but it works in the "dir" command.

The basic problem seems to be that csc does not tolerate this syntax. If
you specify a response file with a path like \\?\C:\director y\response.rsp
, then csc.exe will choke. I am guessing that the Process.Start() is
performing a search for the "csc.exe" command when it is not qualified. it
finds it and normalizes the path to
\\?\C:\WINDOWS\ Microsoft.NET\F ramework\v1.1.4 322\csc.exe . (note: exe).
The csc command then looks for the rsp file from the same dir, using the
same path. Boom.

So your workaround seems appropriate - just specify the path to csc.exe, it
suppresses the search, and you get the friendly filename for csc.rsp, which
csc.exe can tolerate. or tell csc to skip the default response file
(/noconfig) .
-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Oi******** ******@TK2MSFTN GP11.phx.gbl...

who is flash remoting?
is this a macromedia thing?
maybe you should be checking with them?

It is a macromedia thing, but the problem is with the csc compiler as you
can see from the error message. We have reproduced the problem completely
independanty of any of the Macromedia products using the following code:

private void Page_Load(objec t sender, System.EventArg s e)
{
string text2 = @"C:\Inetpub\ww wroot\flashremo ting\bin";
string text4 = @"ExampleWebSer vice";
Process process2 = new Process();
process2.StartI nfo.WorkingDire ctory = text2;
// process2.StartI nfo.FileName =
@"C:\WINDOWS\Mi crosoft.NET\Fra mework\v1.1.432 2\csc.exe";
// With the line below in place, it executes correctly,
// but the line below causes it to fail!
process2.StartI nfo.FileName = "csc.exe";
process2.StartI nfo.CreateNoWin dow = false;
process2.StartI nfo.UseShellExe cute = false;
process2.StartI nfo.ErrorDialog = true;
process2.StartI nfo.RedirectSta ndardOutput = true;
string[] textArray1 = new string[5] { "/out:", text4, ".dll /t:library ",
text4, ".cs" } ;
process2.StartI nfo.Arguments = string.Concat(t extArray1);
process2.Start( );
string stderr = process2.Standa rdOutput.ReadTo End();
process2.WaitFo rExit(30000);
Trace.Write("ex it code", process2.ExitCo de.ToString());
Trace.Write("st dout",stderr);
}

You can try this yourself.. just provide it with a basic CS file for it to
compile in the BIN folder called "ExampleWebServ ice.cs" which can probably
contain any code.

On my machine this will cause the following error to appear in the Trace
output:
fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too long
or invalid

So this problem is not actually related to Macromedia products in any
way - I probably shouldn't have mentionned it - it's simply what I was
working with when I noticed this problem.

Any ideas why this is happening? I'm not sure what the .rsp file is for,
but it's obviously getting an invalid path from the environment or
configuration file somewhere. Note from the comment that if you provice
the full path to the csc.exe file in the code, then it works fine (I can't
actually use that as a solution as the code above is not my code and was
obtained using Reflector).

Thanks,

Nick...

Dino Chiesa [Microsoft] wrote:

who is flash remoting?
is this a macromedia thing?
maybe you should be checking with them?

-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Ox******** ******@TK2MSFTN GP12.phx.gbl...

Hi,

I'm having problems using Flash Remoting with Web Services for ASP.NET
and I've narrowed the problem down to csc.exe when it tries to compile
the stub class.

Flash Remoting (flashgateway.d ll) is calling the following command line
to compile the stub class:

"csc.exe" /out:ExampleWebS ervice.dll /t:library ExampleWebServi ce.cs

If I run that command manually, it correctly generates the DLL and the
application works, so why can't it generate the DLL file when it
compiles it automatically? What's the difference between me running it
from the command line and Flash running it as the ASPNET user?

We then did some more research and have found that csc.exe is producing
the following error while trying to compile the file:

fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too
long or invalid

I've searched for this error everywhere and I can't see that anyone else
has ever encountered it. I've even tried reinstalling .NET in case my
installation was messed up. Where is csc.exe getting the above string
from? (ie where do I look to fix it, and what should it be?)

I can't work out what this error means. I expect it relates to the
extraneous characters on the front of the path but I don't know why
that's happening or why those characters are there.

Do you know how I can fix this problem?

Thanks,

Nick...

[Nick Gilbert]

Thanks for your detailed analysis. The problem is, the code snippet that
I put in the ASPX page is actually code taken from a 3rd party DLL that
I do not have control over... I cannot edit that DLL and the code you
are seeing was not the real source code but was generated by decompiling
the DLL using Reflector. The code works fine on other people's machines
so I'm not sure why it's broken on mine. Perhaps I have different
environment variables set up, but I've tried changing the path but it
didn't make any difference.

I still don't quite understand the problem. I do not think that hard
coding the path to the csc.exe file is a good solution - because the
code will then break if it's installed on any machine which does not
have csc.exe on that exact drive/path. Currently it looks for it in the
path which is sensible behavior and seems to work OK on other people's
machines.

Nick...

Dino Chiesa [Microsoft] wrote:

if I understand you properly, then
- the problem is that csc.exe is returning something strange
- it happens only when CSC is run from an ASPX page
- if you specify the fully-qualified path for CSC then no problem

Seems like you have a good workaround?

Another workaround is to specify the /noconfig option to csc.exe.
http://msdn.microsoft.com/library/en...noreCscrsp.asp

The csc.rsp string you see is not a made-up name - it is the default
"response file" for the csc command. (what is a response file? If you run
csc.exe @foo.rsp , then CSC will process options from the given rsp file,
known as a response file. ) It is using a kind-of strange UNC path syntax,
but it works in the "dir" command.

The basic problem seems to be that csc does not tolerate this syntax. If
you specify a response file with a path like \\?\C:\director y\response.rsp
, then csc.exe will choke. I am guessing that the Process.Start() is
performing a search for the "csc.exe" command when it is not qualified. it
finds it and normalizes the path to
\\?\C:\WINDOWS\ Microsoft.NET\F ramework\v1.1.4 322\csc.exe . (note: exe).
The csc command then looks for the rsp file from the same dir, using the
same path. Boom.

So your workaround seems appropriate - just specify the path to csc.exe, it
suppresses the search, and you get the friendly filename for csc.rsp, which
csc.exe can tolerate. or tell csc to skip the default response file
(/noconfig) .
-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Oi******** ******@TK2MSFTN GP11.phx.gbl...

> who is flash remoting?
> is this a macromedia thing?
> maybe you should be checking with them?

It is a macromedia thing, but the problem is with the csc compiler as you
can see from the error message. We have reproduced the problem completely
independanty of any of the Macromedia products using the following code:

private void Page_Load(objec t sender, System.EventArg s e)
{
string text2 = @"C:\Inetpub\ww wroot\flashremo ting\bin";
string text4 = @"ExampleWebSer vice";
Process process2 = new Process();
process2.StartI nfo.WorkingDire ctory = text2;
// process2.StartI nfo.FileName =
@"C:\WINDOWS\Mi crosoft.NET\Fra mework\v1.1.432 2\csc.exe";
// With the line below in place, it executes correctly,
// but the line below causes it to fail!
process2.StartI nfo.FileName = "csc.exe";
process2.StartI nfo.CreateNoWin dow = false;
process2.StartI nfo.UseShellExe cute = false;
process2.StartI nfo.ErrorDialog = true;
process2.StartI nfo.RedirectSta ndardOutput = true;
string[] textArray1 = new string[5] { "/out:", text4, ".dll /t:library ",
text4, ".cs" } ;
process2.StartI nfo.Arguments = string.Concat(t extArray1);
process2.Start( );
string stderr = process2.Standa rdOutput.ReadTo End();
process2.WaitFo rExit(30000);
Trace.Write("ex it code", process2.ExitCo de.ToString());
Trace.Write("st dout",stderr);
}

You can try this yourself.. just provide it with a basic CS file for it to
compile in the BIN folder called "ExampleWebServ ice.cs" which can probably
contain any code.

On my machine this will cause the following error to appear in the Trace
output:
fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too long
or invalid

So this problem is not actually related to Macromedia products in any
way - I probably shouldn't have mentionned it - it's simply what I was
working with when I noticed this problem.

Any ideas why this is happening? I'm not sure what the .rsp file is for,
but it's obviously getting an invalid path from the environment or
configuration file somewhere. Note from the comment that if you provice
the full path to the csc.exe file in the code, then it works fine (I can't
actually use that as a solution as the code above is not my code and was
obtained using Reflector).

Thanks,

Nick...

Dino Chiesa [Microsoft] wrote:

who is flash remoting?
is this a macromedia thing?
maybe you should be checking with them?

-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Ox******** ******@TK2MSFTN GP12.phx.gbl...
Hi,

I'm having problems using Flash Remoting with Web Services for ASP.NET
and I've narrowed the problem down to csc.exe when it tries to compile
the stub class.

Flash Remoting (flashgateway.d ll) is calling the following command line
to compile the stub class:

"csc.exe" /out:ExampleWebS ervice.dll /t:library ExampleWebServi ce.cs

If I run that command manually, it correctly generates the DLL and the
application works, so why can't it generate the DLL file when it
compiles it automatically? What's the difference between me running it
from the command line and Flash running it as the ASPNET user?

We then did some more research and have found that csc.exe is producing
the following error while trying to compile the file:

fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too
long or invalid

I've searched for this error everywhere and I can't see that anyone else
has ever encountered it. I've even tried reinstalling .NET in case my
installation was messed up. Where is csc.exe getting the above string
from? (ie where do I look to fix it, and what should it be?)

I can't work out what this error means. I expect it relates to the
extraneous characters on the front of the path but I don't know why
that's happening or why those characters are there.

Do you know how I can fix this problem?

Thanks,

Nick...

[Dino Chiesa [Microsoft]]

> Thanks for your detailed analysis. The problem is, the code snippet that I

put in the ASPX page is actually code taken from a 3rd party DLL that I do
not have control over...
if it's a third-party DLL, then you have something to tell that third party.
their stuff breaks under certain conditions.

I'm not saying that csc.exe is not also at fault here - it may be. you may
wish to contact MS support to file a bug. Do you have a support contract?
(sorry, I know this is frustrating - but I am not support staff and cannot
do this on your behalf).
I still don't quite understand the problem. I do not think that hard
coding the path to the csc.exe file is a good solution - because the code
will then break if it's installed on any machine which does not have
csc.exe on that exact drive/path.
I wouldn't suggest hard coding, but if you allow the code to find csc.exe by
examining the registry, that may work.

Something else to try may be: adding
C:\WINDOWS\Micr osoft.NET\Frame work\v1.1.4322

the the PATH for ASPNET, or whatever user the ASP.NET code is running under.
You said you mucked with the path without success.
-D
"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Of******** ******@TK2MSFTN GP15.phx.gbl...
I cannot edit that DLL and the code you are seeing was not the real source code but was generated by decompiling
the DLL using Reflector. The code works fine on other people's machines so
I'm not sure why it's broken on mine. Perhaps I have different environment
variables set up, but I've tried changing the path but it didn't make any
difference.

I still don't quite understand the problem. I do not think that hard
coding the path to the csc.exe file is a good solution - because the code
will then break if it's installed on any machine which does not have
csc.exe on that exact drive/path. Currently it looks for it in the path
which is sensible behavior and seems to work OK on other people's
machines.

Nick...

Dino Chiesa [Microsoft] wrote:

if I understand you properly, then
- the problem is that csc.exe is returning something strange
- it happens only when CSC is run from an ASPX page
- if you specify the fully-qualified path for CSC then no problem

Seems like you have a good workaround?

Another workaround is to specify the /noconfig option to csc.exe.
http://msdn.microsoft.com/library/en...noreCscrsp.asp

The csc.rsp string you see is not a made-up name - it is the default
"response file" for the csc command. (what is a response file? If you
run csc.exe @foo.rsp , then CSC will process options from the given rsp
file, known as a response file. ) It is using a kind-of strange UNC path
syntax, but it works in the "dir" command.

The basic problem seems to be that csc does not tolerate this syntax.
If you specify a response file with a path like
\\?\C:\director y\response.rsp , then csc.exe will choke. I am guessing
that the Process.Start() is performing a search for the "csc.exe" command
when it is not qualified. it finds it and normalizes the path to
\\?\C:\WINDOWS\ Microsoft.NET\F ramework\v1.1.4 322\csc.exe . (note: exe).
The csc command then looks for the rsp file from the same dir, using the
same path. Boom.

So your workaround seems appropriate - just specify the path to csc.exe,
it suppresses the search, and you get the friendly filename for csc.rsp,
which csc.exe can tolerate. or tell csc to skip the default response
file (/noconfig) .
-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Oi******** ******@TK2MSFTN GP11.phx.gbl...

> who is flash remoting?
> is this a macromedia thing?
> maybe you should be checking with them?

It is a macromedia thing, but the problem is with the csc compiler as
you can see from the error message. We have reproduced the problem
completely independanty of any of the Macromedia products using the
following code:

private void Page_Load(objec t sender, System.EventArg s e)
{
string text2 = @"C:\Inetpub\ww wroot\flashremo ting\bin";
string text4 = @"ExampleWebSer vice";
Process process2 = new Process();
process2.StartI nfo.WorkingDire ctory = text2;
// process2.StartI nfo.FileName =
@"C:\WINDOWS\Mi crosoft.NET\Fra mework\v1.1.432 2\csc.exe";
// With the line below in place, it executes correctly,
// but the line below causes it to fail!
process2.StartI nfo.FileName = "csc.exe";
process2.StartI nfo.CreateNoWin dow = false;
process2.StartI nfo.UseShellExe cute = false;
process2.StartI nfo.ErrorDialog = true;
process2.StartI nfo.RedirectSta ndardOutput = true;
string[] textArray1 = new string[5] { "/out:", text4, ".dll /t:library
", text4, ".cs" } ;
process2.StartI nfo.Arguments = string.Concat(t extArray1);
process2.Start( );
string stderr = process2.Standa rdOutput.ReadTo End();
process2.WaitFo rExit(30000);
Trace.Write("ex it code", process2.ExitCo de.ToString());
Trace.Write("st dout",stderr);
}

You can try this yourself.. just provide it with a basic CS file for it
to compile in the BIN folder called "ExampleWebServ ice.cs" which can
probably contain any code.

On my machine this will cause the following error to appear in the Trace
output:
fatal error CS2021: File name
'\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too
long or invalid

So this problem is not actually related to Macromedia products in any
way - I probably shouldn't have mentionned it - it's simply what I was
working with when I noticed this problem.

Any ideas why this is happening? I'm not sure what the .rsp file is for,
but it's obviously getting an invalid path from the environment or
configuration file somewhere. Note from the comment that if you provice
the full path to the csc.exe file in the code, then it works fine (I
can't actually use that as a solution as the code above is not my code
and was obtained using Reflector).

Thanks,

Nick...

Dino Chiesa [Microsoft] wrote:
who is flash remoting?
is this a macromedia thing?
maybe you should be checking with them?

-D

"Nick Gilbert" <ne**@nickgilbe rt.com> wrote in message
news:Ox******** ******@TK2MSFTN GP12.phx.gbl...
> Hi,
>
> I'm having problems using Flash Remoting with Web Services for ASP.NET
> and I've narrowed the problem down to csc.exe when it tries to compile
> the stub class.
>
> Flash Remoting (flashgateway.d ll) is calling the following command
> line to compile the stub class:
>
> "csc.exe" /out:ExampleWebS ervice.dll /t:library ExampleWebServi ce.cs
>
> If I run that command manually, it correctly generates the DLL and the
> application works, so why can't it generate the DLL file when it
> compiles it automatically? What's the difference between me running it
> from the command line and Flash running it as the ASPNET user?
>
> We then did some more research and have found that csc.exe is
> producing the following error while trying to compile the file:
>
> fatal error CS2021: File name
> '\\?\C:\WINDOWS \Microsoft.NET\ Framework\v1.1. 4322\csc.rsp... ' is too
> long or invalid
>
> I've searched for this error everywhere and I can't see that anyone
> else has ever encountered it. I've even tried reinstalling .NET in
> case my installation was messed up. Where is csc.exe getting the above
> string from? (ie where do I look to fix it, and what should it be?)
>
> I can't work out what this error means. I expect it relates to the
> extraneous characters on the front of the path but I don't know why
> that's happening or why those characters are there.
>
> Do you know how I can fix this problem?
>
> Thanks,
>
> Nick...