WindowsとEmbeddedの開発者としての長いキャリアの中で、ほんの数か月前に運命がLinuxを真剣に思いついたことがたまたまありました。 それほど複雑ではないコンソールプログラムを書く必要がありました。 当時、Linuxについての私の知識はすべて、大学のオペレーティングシステムのコース（10年前）から得たものです。 しかし、Stackoverflow、Google、および経験により、タスクに迅速に対処することが可能になりました。 最終的に、すべてがUbuntu 14.04のVisual Studio Codeで記述されました。 確かに、LinuxアプリケーションはWindowsサーバーの小さなクライアントにすぎませんでした。 そのため、Visual Studioのメインプロジェクトから切り離されたため、結果は私を本当に満足させるものではありませんでした。 そして今だけ、 Visual C ++ for Linux Developmentを使用して、コードをメインプロジェクトに転送できました。 その過程で、関連するいくつかの問題を解決する必要がありました。 これについては、カットの下に座ります。
したがって、Visual C ++ for Linux開発はVisual Studioの拡張機能であり、Windowsの使い慣れたIDEでコードを記述し、ターゲットオペレーティング環境（Linux）で直接デバッグできます。 GCCとリモートGDBデバッガーを使用します。 拡張の詳細については、開発者のブログやhabrの翻訳を読むことができます。
インストール、実行、構成などの方法に関する指示 上記のリンクで見つけることができます。 私はこれで問題はありませんでした。 Linuxシステムからの質問。 私がUbuntu 14.04 LTSを使用していることを思い出させてください。残りの議論はそれについてです。 興味のある方は、 osboxes.orgの VirtualBoxの画像を使用しました 。
また、私はあまり私をscらないようにお願いします。私はまだLinuxの第一人者ではありません。 より最適な方法で何かを行えるかどうかを教えてください。
最初のプログラムのデバッグ
リモートデバッグを使用する前に、Linuxシステムにいくつかのコンポーネントをインストールする必要があります。 上記のリンクの指示に示されているように、これはコマンドプロンプトで次の操作を行うことで実行できます。
sudo apt-get install openssh-server g++ gdb gdbserver
Ctrl + Alt + Tを押すと、Ubuntuでターミナルを呼び出すことができます。
この経済がすぐに始まるかどうかは覚えていないので、念のため再起動できます。
すべてが正しく行われると、ポート22が開きますnmap
コマンドを使用してこれを確認できます。
しかし、何らかの理由でシステムが1人のユーザーの下で私を許可しなかったため、Visual Studioからすぐに接続できませんでした。 別のものを作成する必要がありました。 これは、 [システム設定]→[ユーザーアカウント]で実行できます。
同時に、右上隅のロック解除ボタンをクリックすることを忘れないでください。
[ ツール]→[オプション]ウィンドウでVisual Studioの接続を構成できます。
これで、テストプロジェクトを開始してデバッグできます。
この場合、Ubuntuでは、ソースコードとアセンブルされたプログラムファイルがコピーされます（プロジェクト設定で無効化されていない場合）。 これらはすべて、 / home / <username> / projectsフォルダーにあります。
私の場合、次のようになりました。
コンソールからLinux自体でプログラムを実行できます。
作業を開始できるようになりました。 ソースファイルをVisual Studioに転送しましたが、何もコンパイルされませんでした。 プロジェクトには、 インクルードディレクトリの .hファイルがないことが判明しました。
接続されたファイル
Linux開発用のVisual C ++とともに、多くのヘッダーファイルがインストールされます。 ここで見つけることができます：
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Linux\include\usr
しかし、これは私のプロジェクトにとって十分ではありませんでした。
開発ブログには次のように書かれています：
Getting your include files Everyone loves IntelliSense, but we're not yet synchronizing the include files from your Linux system. Everyone has their own ways to either share or copy these files which is great.
彼らは将来この問題を解決することを約束しますが、今は好きなように向きを変えます。 また、 PuTTYを使用して / usr / includeディレクトリ全体をコピーする例もあります。
しかし、私はこの方法が好きではありません。 個人的には、フォルダーをヘッダーファイルと共有することを好みます。 コンソールでコマンドを実行して、インクルードファイルを検索するためのディレクトリのリストを表示できます。
$ touch ac $ gcc -v -E ac
/usr/include
フォルダで十分でした。
私のバージョンのシステムの場合、このフォルダーを共有する前に、現在のユーザーに転送する必要があります。 これは、コマンドsudo chown -R osboxes:test '/usr/include'
ます。
その後、フォルダへのアクセスを開くことができます。 それをする方法はここに書かれています 。
その後、ネットワークパスをVisual Studioでインクルードディレクトリとして指定できます。
このアプローチには、元のヘッダーファイルを常に使用するため、何も同期する必要がないという利点があります。 一方、開発を別のコンピューターに移行する際には問題が発生します。 また、すでに書いたように、コンピューターの仮想マシンにインストールされたUbuntuで作業します。 この構成では、セキュリティの問題が脇にあります。
しかし、他の構成では、上記で説明したアクションが禁止される場合があります。
したがって、ヘッダーファイルの同期の問題は、作業条件に基づいて解決する必要があります。 ここでの選択はあなた次第です。
追加のコンパイラーとリンカーのコマンド
ヘッダーファイルが表示され、コンパイルが成功しました。 しかし、プロジェクトはリンクできませんでした。 実際には、ストリームとヘッダーファイル「pthread.h」を使用しています。 リンカがpthreadライブラリを参照するには、 -pthreadまたは-lpthreadオプションを使用する必要があります。
これらの目的のために、Linux開発用のVisual C ++には特別な設定があります。
しかし、何らかの理由で、それは私のために機能しません。 この問題は一時的なものです（開発者はすでにそれを知っています）が、ここで解決する必要があります。 別のオプションを使用してこのエラーを回避できます。
g ++の代わりにg ++ -pthreadと書くと、正しいリンカー行が得られます。
同じトリックがコンパイラーでも機能します。
管理者権限でデバッグを実行する
これですべてがコンパイルおよびリンクされました。 ただし、入力デバイスファイルを開くため、プログラムには昇格されたアクセス許可が必要です。 したがって、管理者権限でデバッグを開始する必要もあります。 現在、Visual C ++ for Linux開発では、このオプションは実装されていませんが、解決策が1つあります。
コマンドでgdbとgdbserverを昇格できます
$ sudo chmod ugo+s /usr/bin/gdb $ sudo chmod ugo+s /usr/bin/gdbserver
このようなアドバイスは、開発者ブログの投稿のコメントに記載されています。
このトリックは機能しますが、安全ではありません。 基本的に、gdbservrに接続するすべてのユーザーにシステムを提供します。 私の構成では、すべてが私のコンピューターのいずれかで実行されているため、これは怖いことではありませんが、他の条件では、そのようなアクションに非常に注意する必要があります。
追加ファイルをコピーする
そして最後の瞬間が残った。 私のプログラムは、テキストファイルから設定を読み取ります。 これはVisual Studioプロジェクトの一部であり、コンパイル中に実行可能ファイルと共にフォルダーにコピーする必要があります。
これは、プロジェクト設定でも実行できます。
残りのソースと同様に、ファイルを単純にコピーするには、[コピーするソース]フィールドにファイルを追加できます：@（SourcesToCopyRemotely）; config.txt
また、[コピーする追加ソース]を使用して別のディレクトリにコピーできます。
この設定の形式
fulllocationpath1:=fullremotepath1;fulllocationpath2:=fullremotepath2
など
私の場合、この行は次のようになります。
$(ProjectDir)config.txt:=$(RemoteOutDir)config.txt;
すべてがうまくいきますが、ここでも問題がありました。
実際、マクロ$（RemoteOutDir）は、文字「〜」で始まるパスに展開されます。
どうやら、このパスはこの設定に関連付けられています。
したがって、すべてをコンパイルするときはうまくいきます。 ただし、ファイルをコピーする場合、何らかの理由で〜はルートディレクトリとしてではなく、単にフォルダ名として認識されます。 つまり、「〜」という名前のフォルダーが作成されます。
私はまだこれに対処することができなかったので、config.txtファイルを手動でコピーしました。 確かに、このためにフォルダのアクセス許可の変更を再度使用する必要がありました。
sudo chown -R osboxes：テスト '/ home / test'
結果は何ですか
個人的には、Visual C ++ for Linux開発拡張機能が助けになったと言えます。 すべての問題といくつかのバグにもかかわらず、彼はLinuxの開発に関連する問題を迅速かつ効率的に解決することができました。
おそらく、もっと便利な方法があることにこれに反対することができますが、私は自分の経験と知識からしか進めませんでした。これはすべて主にWindowsに関連しています。
ps最近、Alexander Popovkin（@ Catharsis96）によってMSPからネットワークにビデオが登場し、このアドオンの概要も説明されています。