「 VisualStudio 」一覧


VisualStudio で for Linux Development


以前に VisualStudio で Linux での開発に向けて色々とやってみましたが、今はまた新しい方法があるようだったので試してみました。今回は Linux 側として Fedora23 を使用してみます。特殊なことはしていないため他のLinux系のものでも適用可能だと思います。

vs_linux_8

これらの環境設定の手順などを説明していきます。 続きを読む


VisualStudio 2015 で Linux アプリの開発&デバッグ


VisualStudio 2015 で別PCで動いている Linux 環境でのアプリ開発およびデバッグということができるかを試してみました。

必要なものは以下の通りです。

  • Linux環境の別ターゲット
  • VisualStudio 2015 を ”Visual C++ Android 開発”付きでインストール

ここでは VisualStudio 2015 Professional, Windows10 Pro (x64) で確認しています。
vs2015-target-linux-11

セットアップ

最低限の必要なものは準備が終わっているものとして、環境構築の説明をしていきます。

Linux側の準備

ここでは少し古いですが CentOS 6.5 の環境があったのでこれで説明します。
Samba を用いて Linux-Windows のファイル共有ができるように設定しておきます。
またコードのコンパイルを Linux で行うために、コンパイラなどのツールチェインをインストールしておきます。

Windows側の準備

Visual Studio GDB Debugger 」という拡張プラグインをインストールします。
これは以下のページからダウンロードすることができます。
https://visualstudiogallery.msdn.microsoft.com/35dbae07-8c1a-4f9d-94b7-bac16cad9c01
VisualStudioGDB.vsix というファイルがダウンロードされるので、ダブルクリックでインストールを行います。
(本プラグインは Microsoft のデジタル署名がついているようでした)

このプラグインが Plink を使うようなので、Putty のページからファイルを取得してきます。
Putty のページ: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

インストールしてしまっても良さそうですが、開発環境に tortoise Git も入っており、こちらが標準で使っている TortoisePlink でないものを設定済みだったりするとかち合うため、安全を考えて zip アーカイブを取得することにします。

そして、これを適当なところに展開します。ここでは C:\tools\putty に展開しました

続きを読む


VisualStudio 2015 と VMwareWorkstation


Windows10 環境にしたこともあり、VisualStudio 2015 も普段使いの環境に追加していました。このときに、 VMware Workstation 12 で仮想マシンを構築・起動をしようとした際に、「64ビットのゲストOSはこのホストではサポートされていません」というエラーメッセージが出てしまいました。

このエラーは、仮想化支援の機能が BIOS で OFF にされていたり、 そもそも CPU が対応していなかったりすることでみるものなのですが、今回はそれら以外でこのエラーを見たのでここにメモしています。

Android 開発もできるようになったとのことで、 VisualStudio 2015 のインストール時に、 Visual Studio Emulator for Android という開発用のエミュレータをインストールしてしまったことにありました。

このエミュレータはクライアント Hyper-V の機能をベースとして使っているようで、これが原因となっていました。

仮想化支援の機能は基本的にはすでに使用されていると次のアプリでは使用できないため、このような症状になったというわけです。(近年は、Nested な仮想化支援環境も構築できるよう進んでいますが、Hyper-V はこのあたり非対応のままのようです)

早速、コントロールパネルから Windows の機能の部分で Hyper-V に関するところを確認してみたら、インストール済みとなっていましたので、チェックを外して無効化しました。この後再起動を要求されます。

再起動後は、 VMwareWorkstation では当初出ていたメッセージが消えました。一方で、案の定ですが VisualStudio の Android エミュレータは使用不可能となっていました。両立できないのは残念ですが、仕方のないことではありますね・・・。


INTEL の INDE 続報


あれからエラーの対処とかやってみた結果、少し進捗があったのでメモしておきます。
VisualStudio でのビルド時に以下のエラーがでてその先に進めないのが問題でした。

この内容はある意味定番で、JAVA_HOME が設定されていないとか、java.exe が見つからないとかそういう話に帰着します。
今回難航していたのは、android.bat を実行したら Android SDK Manager が起動するし、 javac とタイプしたら実行されるし、とパス情報は正しく設定されているようだったのに、上記のエラーが出てしまう、という点にありました。 続きを読む


インテル INDE インストールから難関


先日のキャンペーンによりインテルの INDE Professional を入手したので、早速試しました(うまくいきませんでしたが)。

どんな風だったかというと、インストールからうまくいかないという感じで導入も大変でした。またエラーによりビルドも正常に出来なかったりと、自分の環境では VisualStudio 2015 RC のほうが使える感じですね。その色々とあった点について書いておきます。 続きを読む


VisualStudio 2015 RC での Androidデバッグ機能


VisualStudio 2015 で Android および iOS のビルドがサポートされる話も有名です。 RC版でも Android に関してはある程度試せる状況にあるようなので、現時点ではどのくらいのことが出来るか試してみようと思います。RC版でのお話なので、正式リリース版では変更になっている可能性が十分にあります。

プロジェクトテンプレート

VS2015RC では既にプロジェクトテンプレートとして以下のように準備がされています。ここでは OpenGLES Application を用いてテストしています。 見ての通り iOS 用もありますが、手元では iOSのビルドをすると、「error : 無効な URI: ホスト名を解析できませんでした。」とエラーになってしまいその先に進めませんでした。また iOS Debugger, Simulator なるものが存在を期待されているようですが謎です。

vs2015rc-cross-platform-template

ちなみに Android 版のサンプルを実行してみた図が以下の通りです。
VS2015RC-ANDROID
見ての通り実機によるデバッグが可能で、その際の各種情報も VisualStudio で表示できています。これらについて詳しく確認していきます。 続きを読む


CRT非依存の続き


前回結構かいたつもりですが、それの補足や追加調査でわかったことを書いておきます。

C++は本当につかえない?

できることならC++のクラスとか使って開発したいですが、new/delete 使えなかった記憶があったので調べてみました。
 結果、通常のnew, delete を使用した際にはCRT依存が発生してしまいます。しかし!グローバルのnewをオーバーロードする方式で new/delete の処理を横取りすれば、この依存が発生しないことがわかりました。個人的にはすばらしい発見でした。(そもそも例外は使わない前提。前回の記事でOFFに設定していますし)

エントリポイントの設定について

前回エントリポイントの設定をするように書きましたが、実は他の方法があるようです。
規定のライブラリ省略をするように設定すると下記の関数がエントリポイントとできるようです。

どのみち規定のライブラリ名の省略オプションは有効にしておいた方がいいみたいですし、こっちのほうがよいのかもしれません。


CRT (C Runtime) に非依存とするために・・・


VisualStudio (Visual C++) を使って開発をしている際にちょっと厄介になってくるのが、CRTの選択についてどれにするかを決める点です。これは実行体(アプリケーション)を作っているときにはまだ軽微な話なのですが、ライブラリを作る際にはとても大変な話になってます。

というのも、デバッグ/リリース、そして、CRTのDLLリンク/スタティックリンクの組み合わせ、最近だとそれに 32bit/64bit という組み合わせを考えなくてはなりません。つまり 2x2x2 の8種類存在することになります。ライブラリの提供者になる場合、特にそのライブラリをパッケージとして納品するなどする場合には、これらの組み合わせのライブラリを1セットとする必要があると思います。

しかし!そんな8種類も納品したくない&動作テストしたくもないのが本音です。
ただ利用者にとっては自分のアプリケーションで使うために、一致するライブラリを選択できているのが望ましいです。数が多いと選択に困るかもしれませんが、ライブラリのせいで構成を縛られてしまう、という点だけは避けたいところです。またオープンソース等であればプロジェクト設定を変更して、利用状況に応じてオプションを変えることで対処することも可能です。・・・でも個人的にはこれもやりたくはない作業だと感じています。

ライブラリの個数を減らすことを考えてみる

8種類もあるのが大変なので減らすことを考えてみます。どうしても減らせないのは 32bit/64bit のケースでしょう。そもそもABIが違うのでこれはどうしようもありません。
ランタイムDLLを要求するケースはclr使う際には必要です。つまりC++/CLIを使って C#から使うようなケースでは必須となります。楽にGUIを作れるのでこれは考慮しておく必要があります。ただCランタイムのDLLについて配布先でインストールが必要になります。おなじみの再頒布ランタイムってやつですね。
スタティックリンクを使用する場合、exe単体配布で動くようにできるというのが最大のメリットでしょう。

つまりDLL/スタティックリンクどちらもメリット・デメリットがあります。つまり捨てられない・・・。

これらのランタイムは何を示しているかを考えてみます。
そう、CRT なので、Cランタイムのタイプがどれであるか、を決めているわけです。ということは、Cランタイムを使わない、CRT非依存を実現できればこれらの問題から解放される、と予想できます。
つまり、CRT非依存を実現できれば DLL/スタティックリンク の組み合わせはどちらでもよい(=最終exeをつくるプロジェクトに任せられる)ということになります。

次に Debug/Release の違いも検討してみます。DLL版においては Debug,Release で別々のランタイムDLLに依存することがわかります(Dependency Walker とか使えば簡単です)。でもやっぱり CRTに関係する実装が Debug/Release と切り替わるだけなので、CRTに非依存が実現できればこのDebug/Releaseの差異も気にしなくてよくなりそうです。

ここまでの予想をまとめると、「CRTに非依存にできれば x86用ライブラリと x64用ライブラリの2つを提供するだけでよくなる!」 となります。非常に魅力的です。
・・・現実問題としてデバッグ用ビルドは用意して提供する気がしますが。組み合わせとして4つ程度で済むというのはとても助かることじゃないでしょうか。

具体的にどう開発をするのか

CRT非依存の開発をするにあたってどうすればいいのか、ホントに実現できるのかという点で自分が調べた範囲でのメモをここに残しておこうと思います。

そもそもCRT非依存にして開発できるのか?という問題ですが、結構手間がかかりますが実現不可能ではありません。このときに使ってよいのは Windows API のみとなります。Cの標準関数は使用不可です。当然ですね。標準関数に含まれる機能が欲しいときには、自作 or Windows API で代替を探す、という感じになります。

たとえば、ファイル操作では fopen, fread, fwrite は使えません。代わりに CreateFile, ReadFile, WriteFile を使用します。printf も使えないので、自力で WriteFile にてコンソール用出力先にデータを書き込む方法で対処とかになります。これは結構大変です・・・。

もうちょっと具体的な話

基本的に C言語の範疇でコードを記述します。
またVisualC++のコンパイラが色々とデバッグ時に役立つ機能を埋め込んでくれるのですが、これらについてオフにします。だいたい以下のような設定をプロジェクトに行います。

  • デバッグ情報: プログラムデータベース(/Zi)
  • SDLチェック: いいえ (/sdl-)
  • 最小リビルドを有効にする: いいえ(/Gm-)
  • C++の例外を有効にする: いいえ
  • 基本ランタイムチェック: 規定
  • セキュリティチェック: いいえ(/GS-)
  • ランタイム型情報を有効にする: いいえ(/GR-)
  • インクリメンタルリンクを有効にする: いいえ
  • エントリポイント: (自分の決めたエントリポイント関数)

また ZeroMemory マクロも実際のところはmemset に展開されるので使用禁止ですし、配列や構造体を={0}のように記述して初期化する際にも memset が使用されてしまうようなのでこれも禁止です。

このようにしてアプリケーションを作っていく際には、慣れないうちには特にですが、ビルドしてできたexeをDependencyWalker で調査しつつ作業を進めるのがよいかと思います。そうしないとどこでCRT依存を混入してしまったのか見つけるのが大変です。


C++で UTF-8文字リテラルを使いたい


VisualStudio 2010 環境限定ではあるけれど、ソースコードがBOM付UTF-8であれ、ShiftJISであれ、文字リテラルを UTF-8 で処理させて、実行体Exeの中に格納できる方法を発見しました。

このようなコードを作成してWindows日本語版の環境下でビルドした場合、その実行体の中に含まれる文字列は、Shift JIS (MS932) となってしまいます。 これはビルド設定の「文字セット」の設定とは無関係で、元のソースコードがどの文字エンコーディングを使っているかにも関係なく、ShiftJISとなってしまうようです。
この状態がちょっと都合が悪いことがあって、出来上がった実行体の中に UTF-8 で文字列で格納しておいてほしいというのが実現したいことです。

すなわち、上記の文字列 「あああ」をエディタで(ShiftJISやUTF-8など)で通常通りに入力し、それをUTF-8化したままで exe の中に格納しておく、ということがやりたいわけです。

続きを読む