Command line compile with csc

[Andrew Warren]

When I build my winforms exe using the IDE I have a
perfectly functioning exe. If I try to build the same
project using the .Net Framework csc compiler I get a
seemingly valid exe produced (although it's only 44 Kb
instead of 76 Kb).

When I then run the csc-compiled exe I immediately get
a "System.TypeIni tializationExce ption".

What am I missing? I'm guessing there may be some batch
file that sets an environment for csc but my installation
of the Framework (v1.1.4322) contains no batch or command
files of any description. I need to get this compiling
in an environment without the full SDK or VS.Net - only
the .Net Framework will be available in the target
environment (should be enough...).

I'd appreciate replies copied to andrew dot warren at
mincom dot com.

Thanks.

[Jon Skeet [C# MVP]]

Andrew Warren <an*******@disc ussions.microso ft.com> wrote:

When I build my winforms exe using the IDE I have a
perfectly functioning exe. If I try to build the same
project using the .Net Framework csc compiler I get a
seemingly valid exe produced (although it's only 44 Kb
instead of 76 Kb).

When I then run the csc-compiled exe I immediately get
a "System.TypeIni tializationExce ption".

What am I missing? I'm guessing there may be some batch
file that sets an environment for csc but my installation
of the Framework (v1.1.4322) contains no batch or command
files of any description. I need to get this compiling
in an environment without the full SDK or VS.Net - only
the .Net Framework will be available in the target
environment (should be enough...).

Do you have a short but complete example which demonstrates the
problem? It sounds very odd to me. Are you referencing any assemblies
other than the "built-in" ones?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Andrew Warren]

Do you have a short but complete example which demonstrates theproblem? It sounds very odd to me. Are you referencing any assembliesother than the "built-in" ones?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

I am using the following "built-ins" across various
classes:

Microsoft.Win32
System
System.Collecti ons
System.Componen tModel
System.Data
System.Diagnost ics
System.Drawing
System.IO
System.Runtime. InteropServices
System.Security
System.Security .Permissions
System.Text
System.Text.Reg ularExpressions
System.Threadin g
System.Windows. Forms
System.Xml

It just occurred to me that one of my classes makes a
call to an unmanaged Windows API that is not available in
the .Net Framework - could this be a factor?

Here is the declaration:
----------------------------------------------------------
[DllImport("kern el32.dll",CharS et=CharSet.Auto ,
SetLastError=tr ue)]

[return:MarshalA s(UnmanagedType .Bool)]

private static extern bool SetEnvironmentV ariable(string
lpName, string lpValue);
----------------------------------------------------------

I compile with the following command line:
csc /out:myapp.exe /win32icon:myico n.ico /target:winexe
*.cs

The .cs files in the current directory include all forms
and classes for the app as well as the AssemblyInfo.cs
created by the IDE.

I can't really give you a complete example that would
also be short! Suffice to say though that apart from that
API call everything else is bog standard - no funny
stuff, just calls to Framework objects. My main form
uses a TreeView control, a DataGrid, and a couple of
buttons - pretty simple. It parses some XML and
populates the TreeView with node objects of my own class
that inherits from TreeNode. Once the tree is built you
can launch command-line sessions based on parameters
supplied by the selected tree node.

[Jon Skeet [C# MVP]]

Andrew Warren <an*******@disc ussions.microso ft.com> wrote:

I am using the following "built-ins" across various
classes:
<snip>

Hmm... they all look okay.
It just occurred to me that one of my classes makes a
call to an unmanaged Windows API that is not available in
the .Net Framework - could this be a factor?
I wouldn't have thought so...
I can't really give you a complete example that would
also be short!

Have you tried? For instance, have you tried writing an app that pretty
much *just* does the unmanaged API call? If that works, you can rule
that out as a reason for the failure.

The other thing you could try is wrapping the Application.Run call in a
try/catch block, and logging more details of the exception to a file.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Philip Rieck]

Andrew : when you compile via the command line, you must include references
yourself.. For example, your application references Microsoft.Win32 ... so
make sure on your "csc" line, you include
"/r:Microsoft.Win 32.dll" or whatever the assembly name is that that's
defined in. Do this for all assemblies you're referencing.

"Andrew Warren" <an*******@disc ussions.microso ft.com> wrote in message
news:06******** *************** *****@phx.gbl.. .

Do you have a short but complete example which

demonstrates the

problem? It sounds very odd to me. Are you referencing

any assemblies

other than the "built-in" ones?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
.

I am using the following "built-ins" across various
classes:

Microsoft.Win32
System
System.Collecti ons
System.Componen tModel
System.Data
System.Diagnost ics
System.Drawing
System.IO
System.Runtime. InteropServices
System.Security
System.Security .Permissions
System.Text
System.Text.Reg ularExpressions
System.Threadin g
System.Windows. Forms
System.Xml

It just occurred to me that one of my classes makes a
call to an unmanaged Windows API that is not available in
the .Net Framework - could this be a factor?

Here is the declaration:
----------------------------------------------------------
[DllImport("kern el32.dll",CharS et=CharSet.Auto ,
SetLastError=tr ue)]

[return:MarshalA s(UnmanagedType .Bool)]

private static extern bool SetEnvironmentV ariable(string
lpName, string lpValue);
----------------------------------------------------------

I compile with the following command line:
csc /out:myapp.exe /win32icon:myico n.ico /target:winexe
*.cs

The .cs files in the current directory include all forms
and classes for the app as well as the AssemblyInfo.cs
created by the IDE.

I can't really give you a complete example that would
also be short! Suffice to say though that apart from that
API call everything else is bog standard - no funny
stuff, just calls to Framework objects. My main form
uses a TreeView control, a DataGrid, and a couple of
buttons - pretty simple. It parses some XML and
populates the TreeView with node objects of my own class
that inherits from TreeNode. Once the tree is built you
can launch command-line sessions based on parameters
supplied by the selected tree node.

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote:

Andrew Warren <an*******@disc ussions.microso ft.com> wrote:

I am using the following "built-ins" across various
classes:

<snip>

Hmm... they all look okay.

I've just looked at them again - they look like namespaces, not
assemblies. What do you have under the References section of your
project?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Philip Rieck <st***@mckraken .com> wrote:

Andrew : when you compile via the command line, you must include references
yourself.. For example, your application references Microsoft.Win32 ... so
make sure on your "csc" line, you include
"/r:Microsoft.Win 32.dll" or whatever the assembly name is that that's
defined in. Do this for all assemblies you're referencing.

Microsoft.Win32 is actually a namespace, not an assembly. The default
response file for csc automatically adds references for all these
assemblies:

Accessibility.d ll
Microsoft.Vsa.d ll
System.Configur ation.Install.d ll
System.Data.dll
System.Design.d ll
System.Director yServices.dll
System.dll
System.Drawing. Design.dll
System.Drawing. dll
System.Enterpri seServices.dll
System.Manageme nt.dll
System.Messagin g.dll
System.Runtime. Remoting.dll
System.Runtime. Serialization.F ormatters.Soap. dll
System.Security .dll
System.ServiceP rocess.dll
System.Web.dll
System.Web.Mobi le.dll
System.Web.Regu larExpressions. dll
System.Web.Serv ices.dll
System.Windows. Forms.Dll
System.XML.dll

Only assemblies not in the above list need to be explicitly referenced.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Philip Rieck]

Sorry - by "whatever that's defined in" -- I should have said "The assembly
that that namespace is defined in"

Since Andrew said that he's trying to do this without installing the SDK,
I'm wondering if he has no default response file, and so will have to
manually add references to all the referenced assemblies when he does a
compile.

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Philip Rieck <st***@mckraken .com> wrote:

Andrew : when you compile via the command line, you must include references yourself.. For example, your application references Microsoft.Win32 ... so make sure on your "csc" line, you include
"/r:Microsoft.Win 32.dll" or whatever the assembly name is that that's
defined in. Do this for all assemblies you're referencing.

Microsoft.Win32 is actually a namespace, not an assembly. The default
response file for csc automatically adds references for all these
assemblies:

Accessibility.d ll
Microsoft.Vsa.d ll
System.Configur ation.Install.d ll
System.Data.dll
System.Design.d ll
System.Director yServices.dll
System.dll
System.Drawing. Design.dll
System.Drawing. dll
System.Enterpri seServices.dll
System.Manageme nt.dll
System.Messagin g.dll
System.Runtime. Remoting.dll
System.Runtime. Serialization.F ormatters.Soap. dll
System.Security .dll
System.ServiceP rocess.dll
System.Web.dll
System.Web.Mobi le.dll
System.Web.Regu larExpressions. dll
System.Web.Serv ices.dll
System.Windows. Forms.Dll
System.XML.dll

Only assemblies not in the above list need to be explicitly referenced.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Philip Rieck <st***@mckraken .com> wrote:

Sorry - by "whatever that's defined in" -- I should have said "The assembly
that that namespace is defined in"

Since Andrew said that he's trying to do this without installing the SDK,
I'm wondering if he has no default response file, and so will have to
manually add references to all the referenced assemblies when he does a
compile.

I wouldn't think so. Bear in mind that he *is* managing to compile it.
It's *running* it that is causing problems. Missing an assembly
reference would mean a failure to compile, not to run.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Andrew Warren]

I ended up logging a call with Microsoft to resolve this
and it turns out that the problem lies with attaching
custom icons to the forms... as soon as the icons are
removed it compiles fine with csc!

There is a workaround - the .resx files for the forms can
be compiled to .resource files using resgen.exe and then
compiled with csc. The downside of this is that it does
not meet my requirement of being able to compile the app
using only the .Net Framework - resgen is part of Visual
Studio.

Still, at least I know what the problem is now!

Thanks for your responses and suggestions. I'll let you
know when I hit on the final solution.