2

I am trying to use csc.exe from the command line to compile a .NET 1.1 .csproj project. It is failing with the following error:

MyProject.csproj(24,2046): error CS1034: Compiler limit exceeded: Line cannot exceed 2046 characters

Line 24 of the .csproj file is the PostBuildEvent attribute of the <Settings> node. I do have a lengthy post build event that exceeds 2046 characters.

This project is a legacy application that has been successfully compiling for 8+ years with no problems up until 2-6 weeks ago. (The last time it successfully compiled for me was over 6 weeks ago and then I didn't try again until a couple weeks ago, and it has been failing ever since.) I tried removing all service packs that have been installed in that time frame and it did not change the result. I am at a loss as to where to go from here.

Edit:

Using Eric J's advice below, I shortened the post build event by moving some of the commands to external .bat files and then calling them like this. Now when I try to run csc.exe, I am getting the following errors:

MyProject.csproj(491,35): error CS1010: Newline in constant

MyProject.csproj(1,1): error CS0116: A namespace does not directly contain members such as fields or methods

Line 491 of the project file is <Folder RelPath = "Xml\" />, and of course line 1 is <VisualStudioProject>.

It's like it's trying to compile my .csproj file as if it were a .cs file. Why? I am calling csc.exe like this:

csc.exe /t:library /out:transformed\Services\bin\Services.dll *.cs Cache\*.cs Settings\*.cs transformed\Services\*.cs /r:MyReference.dll /r:MySecondReference.dll /nologo /debug /define:DEBUG

Is it seeing *.cs and all of a sudden including MyProject.csproj for some reason? If so, how would I get around this?

Edit 2:

I came up with a workaround. As you can see from the command line statement above, I was compiling *.cs, which is in the same directory as the .csproj file. I had a hunch that for some reason, it was also trying to compile the project file as if it were C# code. I moved all C# source files that were in the root directory to a folder called Services, and then changed my command line statement to compile Services\*.cs. Everything works fine now.

I still don't know what caused this behavior to change recently, so if anyone has some insight I would appreciate it.

Community
  • 1
  • 1
egbrad
  • 2,387
  • 2
  • 23
  • 27
  • 3
    Have you considered, you know, making the line shorter? Or update your 10 year old version of VS? VS2005 and up have a limit of 16 million chars. – Hans Passant Oct 07 '13 at 18:13
  • @HansPassant: How could you possibly know that offhand? Have you been dealing with insane build scripts? :) – SLaks Oct 07 '13 at 18:14
  • @SLaks - it is documented in the MSDN article for CS1034 :) – Hans Passant Oct 07 '13 at 18:15
  • @HansPassant No one uses VS2003 by choice. :) I inherited this app. It is currently being rewritten, but that is ~6 months from being completed and I need to support this old app for the time being. – egbrad Oct 08 '13 at 13:19
  • Well, don't rewrite it. Just open the project it in a newer version of VS. – Hans Passant Oct 08 '13 at 13:21
  • @HansPassant It is using csc.exe which is a command line tool to compile generated code. I can reproduce this problem from the command line, not using Visual Studio at all. You can't use the 2.0+ version of csc.exe to compile 1.1 code, can you? – egbrad Oct 08 '13 at 13:22
  • What on Earth gave you that idea? – Hans Passant Oct 08 '13 at 13:30
  • Ha! Well as I said, I inherited this app. But evidently, there was a lot of boilerplate code that had to be written for asmx web services back in the day, so someone wrote a tool to generate all the contracts, senders, receivers, etc. and then the post build event compiles it and pushes it around to where it needs to go. – egbrad Oct 08 '13 at 13:40

2 Answers2

1

I'm not sure what would have changed to cause the post build event to fail suddenly, but you may be able to resolve the issue by creating a batch file or PowerShell script that encapsulates the lengthy event and call that script instead.

Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • This helped me get over the "compiler limit exceeded" hump, but I think the underlying issue is that it's trying to compile my .csproj file as if it were C# code. See my edit above. Do you have any thoughts? – egbrad Oct 07 '13 at 19:45
  • If you temporarily remove the .csproj and execute that `csc` command line, what happens? All I can think is perhaps some strange error in pattern matching such that *.cs matches .csproj though never seen that happen. Are you using the current version of csc.exe or a legacy version? You can use the latest one and still target the .NET 1.1 framework afaik. – Eric J. Oct 08 '13 at 21:04
  • Yeah I figured there must be a change in the pattern matching as well. I moved the .cs files into a subdirectory and then targeted that subdirectory from my csc.exe script, and it compiled. Something must have changed on my machine through some organizational policy or something. I don't know why the behavior of csc.exe would suddenly change. It has happened on some of my other team members' machines as well lately. I am going to mark this as the answer because it helped me solve the problem. Thanks! – egbrad Oct 09 '13 at 15:56
0

Here is what I think has happened. In the post-build you have a Macro, something like $(TargetPath). You might changed location where your project sits and the path in $(TargetPath) became very long. Try to move your build to some simple directory, like "C:\build" and see if it will compile.

Then, if no success, try to compile your project using devenv.exe as command line, or just in visual studio. If that doesn't work, try to re-format your post-build event so that lines are shorter.

T.S.
  • 18,195
  • 11
  • 58
  • 78
  • I had been thinking along the same lines, but (1) I don't think any of my project locations have changed, and (2) the post build event would be over 5100 characters even if every macro'd path was c:\build. – egbrad Oct 07 '13 at 18:33
  • do something to narrow down to the issue. First step - remove post-build events and try compile. If compiles - PB is the issue. I bet, you have some "variable" data that changed for post-build and it created line that is too long – T.S. Oct 07 '13 at 18:39