問題タブ [csc]

特にオブジェクト初期化子の使用に関して、TeamCity (v4.0) でプロジェクトの 1 つを設定する際に問題が発生しています。

プロジェクトは正常にビルドされますが、TeamCity はビルド ファイルを好みのもの (MSBuild の突然変異) に変換し、ソリューションの一部のコードをコンパイルする際に、オブジェクト初期化子が表示されると中断します。

具体的には、エラーは次のとおりです。

これをさらに詳しく調べると、v2.0 フレームワーク ディレクトリから CSC を使用してビルド ファイルを TeamCity 形式に変換することに問題があるように思われます。

.NET 2.0 コンパイラでオブジェクト初期化子 (.NET 3.0 の機能) を使用してコードをコンパイルすることは可能ですか? 3.0 コンパイラ (存在する場合) または 3.5 コンパイラ?

興味のある方のために、実行されている CSC コマンドは次のとおりです。

ありがとう！

更新: ビルド ランナーを Nant からコマンド ランナーに変更することで問題を部分的に修正しました (読んだ: 満足していません)。フィードバック レベルは違う。他の提案をいただければ幸いです。

C# コマンド ライン コンパイラの /lib スイッチに関する MSDN の記事では、次のように指定されています。

コンパイラは、完全修飾されていないアセンブリ参照を次の順序で検索します。

• 現在の作業ディレクトリ。これは、コンパイラが呼び出されるディレクトリです。

• 共通言語ランタイム システム ディレクトリ。

• /lib で指定されたディレクトリ。

• LIB 環境変数で指定されたディレクトリ。

CLR ランタイム システム ディレクトリがシステム上のどこにあるかをプログラムでどのように判断しますか?

私は Remotesoft Linker と Mini Deployment ツールを使って、マネージ コードから単一のネイティブ実行可能ファイル (フレームワークのインストールを必要としない) を作成する実験を行ってきました。構成可能な機能の 1 つは、csc.exe が最終的な実行可能ファイルに使用できるかどうかです。そのドキュメントには、通常、XML シリアライゼーションを使用する場合にのみ必要であると書かれています (私はそうです)。SGen を使用してシリアル化アセンブリを作成するようにビルド プロセスを変更し、xml クラスを使用するソリューション内の各プロジェクトの参照に結果を追加しました。シリアル化クラスは、リンクされた .net 実行可能ファイル (すべての .net dll が 1 つのマネージド exe に結合されたもの) になります。したがって、適切に構成されていると思います。

ただし、私のアプリは実行時に csc を実行しようとします。シリアライゼーション アセンブリに何か問題があり、実行時に再作成されているのでしょうか。または、私のアプリはcscを必要とする何か他のことをしていますか?どうすれば何を判断できますか?

http://www.remotesoft.com/linker/

ビルドの一部として Xml Serialization アセンブリを生成する

編集：変更された app.config を使用していくつかのテストを行い、シリアル化ファイルが生成された場合に表示されるようにしました（ビルド時の生成を元に戻すことによってテストされました）。以前は適切に作成していたようです。実行時に csc を呼び出し、別のフラグを使用してその結果を再表示するフレームワークの別の部分がない限り、おそらく RemoteSoft ツールが原因であると思います。ただし、出力された実行可能ファイルは、注入された app.config ファイルが指示したとしても、作成した一時ファイルを表示したままにしないため、確信が持てません。

私が使用したapp.infoはこれでした。他の場所で値 4 を使用した例を見ましたが、それらの動作の違いを見つけることができませんでした。

コマンドラインからプロジェクトをビルドしたい。Visual Studioをインストールせずに C# コンパイラをデプロイすることはできますか?

私は csc.exe からコンパイルしています (まあ、CruiseControl は...)、GAC で DLL を参照する必要があります。この DLL の正しいバージョンを単純なファイルとして持っていませんが、GAC には正しいバージョンがあります。

ただし、csc を使用して GAC 内のアセンブリを参照することはできません。実際のファイルへのパスが必要です。

実際のファイルへのパスをリバース エンジニアリングできると主張する参考文献をいくつか見つけましたが、それらを機能させることができませんでした。Fusion のログを起動したところ、ランタイムがファイルを取得している場所を確認できましたが、リファレンスでその場所へのファイルパスを使用しても機能しません。

では、GAC にのみ存在するアセンブリ バージョンへの参照を csc に提供するにはどうすればよいでしょうか。

ソリューション全体はVisualStudioで正常に構築されますが、Nantスクリプトを実行してWebサイトをコンパイルすると、次の行でいくつかのエラーが発生します。

最初に「TypeExpected」と表示され、次に構文エラー（値が期待される）、）が「expected」と表示されます。プロジェクトで以前にこのような行を使用したことがありますが、それらについては文句を言わないようです。

その条件文でSplitを呼び出すことでエラーが発生していることは確かですが、理由はわかりません。

大きな文字列constを持つクラスを生成する必要がある状況があります。私の制御外のコードにより、生成されたCodeDomツリーがC＃ソースに発行され、後でより大きなアセンブリの一部としてコンパイルされます。

残念ながら、この文字列の長さがWin2K8 x64では335440文字（Win2K3 x86では926240文字）を超えると、C＃コンパイラが致命的なエラーで終了するという状況に遭遇しました。

致命的なエラーCS1647：式が長すぎるか複雑すぎて、「int」の近くでコンパイルできません

MSDNによると、CS1647は「コンパイラのスタックオーバーフロー」です（しゃれは意図されていません！）。もっと詳しく見てみると、CodeDomは文字列constを80文字で「うまく」ラップしていると判断しました。これにより、コンパイラは4193文字列チャンクを連結します。これは明らかにx64 NetFxのC＃コンパイラのスタック深度です。CSC.exeは、この式を内部的に再帰的に評価して、単一の文字列を「再水和」する必要があります。

私の最初の質問はこれです：「コードジェネレーターが文字列を出力する方法を変更するための回避策を知っている人はいますか？」外部システムがC＃ソースを中間として使用するという事実を制御できず、これを定数にしたい（むしろ文字列の実行時の連結よりも）。

あるいは、特定の文字数の後でも定数を作成できるが、複数の大きなチャンクで構成されるように、この式をどのように定式化できますか？

完全な再現はここにあります：

Visual Studio 2008 (MSBuild) で同じソースをコンパイルし、次にコマンド ラインで csc (または NANT) を使用してコンパイルすると、正確に同じバイナリ ファイル (同じアセンブリ) を取得できない理由がわかりません。

コマンド ラインは、出力ウィンドウからコマンドをコピーして vs2008 コマンド プロンプトに貼り付けるため、Visual Studio で呼び出されるものと同じです。

同じソースを別の時点でコンパイルすると、アセンブリ メタデータのタイムスタンプが原因で別のバイナリが取得されることはわかっています。実際、vs2008 によって別の時点で生成された 2 つのバイナリを比較すると、バイナリ データのわずかな違いに気付きます。

しかし、vs でコンパイルしてから csc でコンパイルすると、バイナリは大きく異なります。なぜなのかご存知ですか？どうしたの？

どの dll を参照する必要があるかという点で、csc.exe を使用してコマンドラインからこのコードを正常にコンパイルするにはどうすればよいですか。Office 2003 だけでなく Office 2007 でも動作するようにしたいと考えています。

私は.Net Framework SDK 2.0を使用しています。

次のコンパイル エラーが発生します。

(2,37): エラー CS0234: 型または名前空間名 'Interop' が名前空間 'Microsoft.Office' に存在しません (アセンブリ参照がありませんか?)

ソースコード：

ナントとCSCで遊んでいます。CSC および nant ビルド スクリプトを介してコンパイルした場合、私の dll のデバッグ バージョンは 140k であることに気付きました。ただし、Visual Studio 環境でデバッグ バージョンをビルドすると、203k になります!? ただし、小さい DLL はメイン プログラムで正常に動作するように見えます。何か案は？