問題タブ [managed-code]

WPFアプリケーションは、その中核となる管理対象アプリケーションですか？ 右？ したがって、マネージC ++とマネージC＃のどちらを使用するかを選択する必要があります。私は何年も前にマネージC++を試しました。プライムタイムの準備が整っていないようです。MicrosoftはマネージC++よりもマネージC＃に力を入れていると思います。したがって、マネージドC＃を使用することが2つの間の最良の代替手段であるように思われます。これは本当ですか？どちらの言語でも、WPFでどのような経験がありますか？前もって感謝します。

.net dll にマネージ コードとアンマネージ コードの両方が含まれている場合、コードを CIL に変換する方法と、CLR がメモリを割り当てて管理する方法

Delphi .exe によって呼び出される単一のメソッドで .Net 3.5 dll を作成しました。残念ながら、うまくいきません。

手順: 1. 次のコードで C# 3.5 dll を作成します。

1. [アセンブリ プロパティ] --> [アセンブリ情報] に移動し、[アセンブリを COM 可視にする] にチェックを入れました。
2. RegAsm.exe を使用して dll を登録しました

これにより、dll に接続できないことを示す Delphi 例外がスローされます。アンマネージド コードから C# マネージド DLL を使用できるようにするために必要な手順は何ですか。

この主題についての良い例に精通している人はいますか?

ありがとうございました

私はC＃を初めて使用し、「windbg」または「Visual StudioDebugger」がマネージコードをデバッグするためのより良いツールになるかどうか疑問に思っていますか？

過去数年間、私はC ++で開発を行っており、 VisualStudioデバッガーと比較してwindbgを快適に使用できます。ただし、マネージコードの場合にもwindbgが最適に機能するかどうかはわかりません。

windbgとVisualStudioDebugger以外に、マネージコードのデバッグでこれらよりも優れたデバッグツールはありますか？

ネイティブ コードに対するマネージ ランゲージの実際の利点は何だろうと思っています。

移植性: C#/Jave にはプラットフォームごとに VM 実装が必要であり、c++ にはコンパイラが必要です。

ガベージ コレクター: メモリの割り当て/解放をチェックするスレッドを C++ で作成できます

反射:ネイティブ コードで同様のメカニズムを使用できる可能性があります (???)

今日、マネージ コードは多くの人気を得ていますが、ネイティブ コードには、一般的により効率的で軽量であるという利点があります。つまり、ターゲット プラットフォームに VM を配置する必要がありません。一方、私によると、マネージド コードはそれほど大きくありません。間違っていますか? マネージ コードは、アプリケーションの大部分で従うべき良い方法ですか?

Cでは、x86マシンにコンパイルすると、条件が複雑な場合でも、たとえば、速度が最も重要な側面である場合、通常、ブランチを論理式に置き換えます。

私は書く：

明らかに、これは保守が難しく、コードが読みにくくなる可能性がありますが、実際には高速である可能性があります。

C＃などのマネージコードを操作するときに同じように動作する理由はありますか？「ジャンプ」は、マネージコードでは（少なくともx86では）マネージコードであるため、コストがかかりますか？

この質問は、このスレッドの結果です。

私の質問は、なぜ一部のパラメーターにMarshalAs属性を指定する必要があるのに、他のパラメーターには指定しないのかということです。c ++とc＃のデータ型の違いは、コンパイラーの指示を必要とするほど大きいと思いましたか？

私の無知を失礼します、なぜならiveはこれまでアンマネージコードを扱ったことがなかったからです:)

乾杯、アダム

昨年 10 月に開催された Microsoft ビルド カンファレンスを見ていましたが、新しい Metro スタイル アプリをビルドするために、開発者が C# でネイティブ コードを記述できると発表していることに気付きました。これはどのように可能ですか？私はただ興味があります。C# は (CLI 標準の一部として) 最初に中間バイト コードにコンパイルされ、次に仮想マシンで実行されるように設計されていませんでしたか? 仮想マシンで実行されるものを「ネイティブ コード」と呼ぶにはどうすればよいですか?

私の質問は、実際のコードではなく、概念に関するものです。

vb.netにアプリがあります。さまざまな理由から、いくつかのクラスをネイティブc ++コード（cliではなく）に移植したいと思います。私がやりたいのは、フルマネージドアプリの場合と同じように、これらのクラスをインスタンス化して使用できるようにすることです。

ネイティブdllから静的関数を呼び出すことができることは理解していますが、ここではそうではありません。クラスをインスタンス化して、アプリの存続期間を通じて使用する必要があります。

だから問題は、これは可能ですか？もしそうなら、あなたは私を始めるための正しい方向に向けることができますか？

最近、VB.NETソリューションをVS2005からVS2010にアップコンバートしているときに、やや厄介な動作に遭遇しました。参考までに、ソリューションは.NET 2.0を対象としており、変換前にデバッガーでエラーなしで実行されていました。IDEの変更に加えて、企業はデバイスをWin XP（x86）からWin 7（x64）に更新するのに適していると考えています。

ソリューションをVS2010に変換したので、デバッガーがロードされるとすぐにソケット例外を受け取ります（詳細は以下を参照）。これはデバッガーでのみ発生します。リリース構成でソリューションを構築すると、エラーなしで正しくインストールおよび実行されるMSIが生成されます。

受け取った例外の詳細は次のとおりです。

本当に紛らわしいのは、この例外が私のコードの1行が実行される前に生成されることです。MainメソッドはVB.NET（マネージコード）を介して生成され、ブレークポイントを設定したり、エラーをトラップしたり（カーネル/アプリケーションのコンテキストの切り替えが原因で）、シンボリックにデバッグしたりすることはできません。

これに対する可能な修正は、別の.NET Frameworkバージョンをターゲットにすることですが、なぜこれが発生するのかを理解することに本当に興味があります。このようなエラーがデバッガーでのみ発生し、リリースされたコードでは発生しない理由を理解できません。そして、はい、私はマシンを再起動して、まだリッスンしている残りのソケットがないことを確認しようとしました。これにより、バインディングが失敗します。

よろしくお願いします。