問題タブ [csc]

プロジェクトの兄弟ディレクトリにある cs ファイルをコンパイルしようとしていますが、csc で開くことができません。問題を引き起こすコマンド ラインのサンプルを次に示します。

Csc は次のメッセージを出力します。

本当に奇妙なのは、「../test」の部分が取り除かれていることです。

誰でもこれを機能させる方法についてアイデアを持っていますか? ありがとう

コマンドラインからいくつかのc#ファイルをコンパイルするのを手伝ってくれる人はいますか? Main、Form1 (2.cs ファイルを使用)、およびプロジェクトで使用される別のクラスの 4 つのファイルをコンパイルします。

/t:library スイッチを追加できるように、このプロジェクトをコマンド ラインでコンパイルしたいと思います (このチュートリアルのように: http://dotnetslackers.com/articles/csharp/WritingAnActiveXControlInCSharp.aspx )。

ただし、「csc /t:library Program1.cs MainForm.cs MainForm.Designer.cs EigenObjectRecognizer.cs」を使用した後、次のようなアセンブリ参照エラーが見つかりません。

EMGUバイナリがインストールされています。EMGU.CV.dll のようなそのフォルダからいくつかの .dll を使用する必要があると思いますか?

これは次のフォローアップです:非同期デリゲート/ラムダを使用したプロジェクション

どうやら、Async CTP には私が遭遇したバグがあり、VS11 コンパイラを使用する必要があります。コマンド ラインでは、msbuildVS11/.NET 4.5 が .NET 4.0 ディレクトリにインプレース インストールされるため、VS2010 で記述されたプロジェクトに対して実行しても、VS11 コンパイラでコンパイルされます。

ただし、Visual Studio 2010 内では、新しい VS11 コンパイラにアップグレードされていないように見えるインプロセス コンパイラが使用されています。

Visual Studio 2010 が使用するコンパイラを (何らかのハッカー/DLL 操作によって) 変更できますか? これは、VS11 が Windows Azure をサポートするまでのハック/回避策にすぎないため、ベータ版/リリース候補版/RTM にアップグレードできます。

c#を使って簡単なプログラムを作ろうとしていGrowl C# APIます。

私は2つの異なる方法でプログラムをコンパイルしようとしました：

1）.dllファイルをファイルと同じディレクトリに保存しました.cs。私が走ったより

それはうまくコンパイルされ、またうまく動作しました。

2）これで、現在の作業ディレクトリ内に名前付きのディレクトリを作成し、growlすべての.dll参照をそこに保持しました。

以下のコマンドを使用してコンパイルしようとすると

正常にコンパイルされましたが、実行しようとすると、以下の例外が発生しました。

だから、私の質問は、ファイルが外部フォルダにあるときにファイル.dllを参照する正しい方法は何ですか？csc

2番目のケースのディレクトリ構造は次のとおりです。

Visual C++ 2010 では、cl.exe に渡されるパラメーターを確認できます。

これは非常に便利です。なぜなら、これまたはそのオプションをチェックするのを忘れたり、あちこちにディレクトリを追加したりするのを忘れる場合があり、一度にすべてのコマンドを表示すると、これを簡単に見つけることができるからです。

Visual C# 2010 にそのようなものがあるかどうか疑問に思っていました。「コマンド ライン」タブがどこにも表示されません。以前のバージョンでは [出力] > [ビルド] タブに "Task: csc" という行が表示されていたようですが、Visual C# 2010 SP1 によって生成された出力にはそのようなものは見つかりませんでした。

私が探しているものを手に入れることは可能ですか？

NB MSBuild からパラメーターを取得できることはわかっていますが、依存関係の解決に失敗したため、残念ながら MSBuild はソリューションの一部をビルドできません。純粋な Visual Studio IDE ソリューションを探しています。

2.0、3.0、3.5、4.0、および4.5を同時に対象とする単一の.NETアセンブリで、C＃とVB.NETの両方のコンシューマーの拡張メソッドをサポートするにはどうすればよいですか？

標準的な提案はこれを追加することです：

このアプローチは、複数のMicrosoft従業員によって提案され、MSDNマガジンでも取り上げられました。多くのブロガーから「悪影響がない」と広く歓迎されています。

ああ、それが.NET3.5以降を対象とするVB.NETプロジェクトからのコンパイラエラーを引き起こすことを除いて。

Microsoft.Core.Scripting.dllの作成者はそれを理解し、「public」を「internal」に変更しました。

これはVBの互換性の問題を解決したようです。

そのため、広く使用されているImageResizing.Netライブラリの最新バージョン（3.2.1）に対して、このアプローチを信頼して使用しました。

しかし、その後、.NET 3.5以降を対象とする特定のユーザーに対して、このコンパイラエラー（元のレポート）が多かれ少なかれランダムに発生し始めます。

MSBuild / VisualStudioコンパイラは、名前の競合を解決するときにスコープルールを気にしないようであり、アセンブリ参照の順序は十分に文書化されていない役割を果たしているため、これが発生する理由と時期を完全には理解していません。

アセンブリ名前空間の変更、プロジェクトファイルの再作成、System.Coreの削除/読み取り、ターゲットバージョンの.NET Frameworkの操作など、いくつかの厄介な回避策があります。残念ながら、これらの回避策はいずれも100％ではありません（エイリアシングを除くが、それは許容できない苦痛です）。

どうすればこれを修正できますか

1. アセンブリ内での拡張メソッドの使用のサポートを維持し、
2. .NET 2.0/3.0のサポートの維持
3. .NETFrameworkのバージョンごとに複数のアセンブリを必要としません。

または、コンパイラにスコープ規則に注意を向けさせるための修正プログラムはありますか？

この質問に答えないSOに関する関連質問

• .NET 2.0のC＃拡張メソッド
• .NETFramework2.0での拡張メソッドの使用
• ExtensionAttributeに関する奇妙な警告
• Asp.NetでIronPythonを使用する場合のExtensionAttributeのあいまいな参照
• .NET 2.0をサポートする必要がありますか？
• .NET 2.0で拡張メソッドを使用していますか？

それを確実にする簡単な方法があるかどうか疑問に思っています.C＃プロジェクトがコンパイルされると、Csc.exe起動されたプロジェクトは親プロセッサのアフィニティ設定を継承します。またはおそらく私がこれを提供できる方法です。

batVS.NET cmd プロンプトからファイルを起動して、これを達成しようとしています。

私のcustombuild.cmd中には：

生成されるコマンド ライン呼び出しCsc.exeは次のようになります。

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe ...(残りは簡潔にするために省略されています。)

プロセッサのアフィニティを継承するか、呼び出しの生成Csc.exe方法をオーバーライドして次のようにする簡単な方法を継承したいと思います。Csc.exe

start /affinity 01 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe ...(残りは簡潔にするために省略されています。)

また、CoreCompile ターゲットが Microsoft.CSharp.targets で定義されていることにも気付きました。MSBuildToolsPath 変数をオーバーライドして、独自のバージョンに忍び込むことを検討する必要があります。これはかなりハッキーに感じます。どんな助けでも大歓迎です。

ステータスの更新: csc タスクによって起動された csc.exe プロセスが、Task クラスのメンバーの ExecuteTool メソッドで実際に準備されていることがわかりました。Csc から派生し、ExecuteTool メソッドをオーバーライドするカスタム タスク CpuAffineCscTask を作成しました。私の目標は、中断された状態で CreateProcess への pinvoke 呼び出しを使用して csc.exe を起動し、アフィニティを設定してからスレッドを再開することです。また、リフレクションを使用して、さまざまな変数の状態を正しく設定するなどしました。現在、MicrosoftCSharp.targets ファイルで定義されている CoreCompile ターゲットをオーバーライドしようとしていますが、ターゲットを実行すると、次のランタイム エラーが発生します。このあたりの既知の例はありますか?cmd全体がmsbuild診断出力に正しく出力されますが。参考までに、診断出力を以下に示します。

タスク "MSBuild.Tasks.CpuAffineCscTask" (TaskId:14) C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /unsafe+ /nowarn:1701,1702 /nostdlib+ /errorreport:prompt /warn: 4 /doc:..\Bin\Release\Ugp.Igt.Core.XML /define:TRACE /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib. dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Core.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\ Microsoft\Framework.NETFramework\v4.0\WindowsBase.dll" /debug:pdbonly /filealign:512 /keyfile:..\StrongNameKeyFile.snk /optimize+ /out:obj\Release\Ugp.Igt.Core.dll /target:ライブラリ ..\DevelopmentKitVersionInfo.cs AnonymousDisposable.cs ByteArrayExtensionMethods.cs TypeMustImplementMethodAttribute.cs WeakEvent.cs "C:\Users\bhatiah\AppData\Local\Temp.NETFramework,Version=v4.0.AssemblyAttributes.cs" (TaskId:14) E:\source\Core\Microsoft.CSharp.targets(217,3): エラー MSB6001: "Csc.exe" のコマンド ライン スイッチが無効です。値を null にすることはできません。E:\source\Core\Microsoft.CSharp.targets(217,3): エラー MSB6001: パラメーター名: SafeHandle を null にすることはできません。 タスク "Igt.MSBuild.Tasks.CpuAffineCscTask" の実行が完了しました -- 失敗しました。(TaskId:14) プロジェクト "Igt.Core.csproj" でターゲット "CoreCompile" をビルドしました -- 失敗しました。: (TargetId:37) ターゲット "_CheckForCompileOutputs: (TargetId:38)" ファイル "c:\Windows\Microsoft.プロジェクト "E:\source\Core\Igt.Core\Igt.Core.csproj" からの NET\Framework\v4.0.30319\Microsoft.Common.targets" (ターゲット "_CleanGetCurrentAndPriorFileWrites" はそれに依存します):

どんな助けでも大歓迎です。

PS: CreateProcess とパイプを使用しているため、3 つの IO ストリームすべてをリダイレクトしていますが、作成後に Process.getProcessById .net メソッドを使用してプロセス オブジェクトへの参照を取得し、ハンドラーをアタッチします。

丈夫な

残念ながら、ほとんど文書化されていない既存のコードを使用していますが、ロードするプラグインのメソッドをどのように呼び出すかを理解するのに苦労しています。

現時点での私の目的は、プラグインマネージャーを介してロードされたメソッドの1つにステップインすることです。これは、例外を引き起こしているためです。ただし、デバッグシンボルを取得するには、ソースからpluginManagerを再構築する必要があり、この新しいDLLバージョンを参照すると、コンパイラがアームをスローします。

コードはプラグインをロードしてから、plug.Instanceそのような特定のメソッドにアクセスするようplug.Instance.ReturnLeaNumber(); に見えます。プラグインの詳細がわからないため、このコンパイラエラーは理にかなっています。私を混乱させるのは、プラグインが初期化されていないときに、コンパイラが実行前に有効な場所をどのように知っていたかです。古いDLLでは機能しないコードをステップスルーできます！

これは、プログラムがプラグインをロードする場所の例です。

再構築されたライブラリと以前に機能していたライブラリとの間に違いがある場合、バージョンがソース管理のバージョンとどのように一致するかわかりません。どこから探し始めるかについてアドバイスをいただければ幸いです。

PasteBinの残りのマネージャーコード

plug.Instance.Method()コンパイラは、実行前にこれらのメソッドをどのように認識しますか？

編集：

私はまだこれを完全には解決していませんが、「GenericPluginServices」を部分的に反映する「PluginsService」ファイルがありませんでした。このエラーは、現在機能していないプラグインに関連するこのクラスの一部を削除したときに発生した可能性があると思います。ただし、この他のコードスニペットを投稿すると質問に役立つと思いました。

PluginService.csコード GenericPluginServiceコード

ビルドマシンにはdmakeを使用し、ローカルでのビルドにはVS2010を使用します。すべてが正常に機能したので、VS2012 RC（最終版）をインストールしました。

Visual Studioで問題なく構築されていますが、次の警告が表示されます。

ただし、dmakeは大量のエラーメッセージをスローし、それらはすべて次のようになります。

エラーメッセージから、チェックインされたバージョンの.NETを使用していることがわかります（特に安定したテスト環境があります）。VS2012のインストールによってVS2010（または少なくともCSC）が発生したようです。これはVS2010に付属しています）、WPFアセンブリの追加のコピーを検索します。

他の誰かがこれに遭遇しますか？私はこれを修正するためにハッキングを開始するいくつかの方法を知っていますが、これを解決するためのより簡単な方法があることを望んでいます。

1 つの .Net c# プロジェクトを複数の dll にコンパイルしようとしています。しかし、ここに問題があります。

これが私のプロジェクト構造です。

このプロジェクトを File1.dll と File2.dll にコンパイルします。File1.dll と File2.dll はどちらも、Dir1 と Dir2 にあるさまざまな .cs ファイルのコードを使用します。サブディレクトリにある .cs ファイル内のこれらのクラスの一部は、File1.cs で必要とされ、その他は File2.cs で必要とされます。File1.cs と File2.cs の両方で使用されるものもあります。

私は以下を使用しました：

しかし、結果として得られる dll は、ファイル名が異なるだけで、お互いの正確なコピーでした。オブジェクト ブラウザーで各 dll を検査するときに、Dir1 と Dir2 の .cs ファイルから、File1.cs 内で File1.dll と同様に参照されているクラスのみが含まれるように、それらをコンパイルする方法はありますか? File2.dll?

Visual Studio でのビルド後のステップの一部として、できればこれを行いたいと考えています。

御時間ありがとうございます...

編集

ご回答ありがとうございます。ソリューションを多くのプロジェクトに分割するための多くの提案がありました。これは 1 つの方法ですが、File1.dll と File2.dll の 2 つの dll に対して作成された依存関係が必要かどうかはわかりません。説明させてください..

複数のプロジェクトを作成する際の問題は、File1.cs と File2.cs の両方に必要なコードがいくつかあることです。両方のプロジェクトでそれらを繰り返したくありません。共通コードを 3 番目のプロジェクトに保持するということは、File1.dll と File2.dll の両方に必要な 3 番目の dll が作成されることを意味します。私はこれをしたくありません。File1.dll と File2.dll のみを作成したいので、両方を 1 つのプロジェクトに保持しています。これを実現する方法について何か提案はありますか?

返信ありがとうございます。

乾杯。