アーカイブ
ODAC 12c Release 4 Visual Studio 2015対応とスキーマ比較の機能追加
ODAC 12c Release 4がダウンロード可能になっています。
OTNダウンロードページ：
http://www.oracle.com/technetwork/topics/dotnet/whatsnew/index.html
NuGet
今回のリリースはVisual Studio 2015への対応とマネージドドライバの機能拡張がほとんどなようですが、個人的に注目すべきはoffline schema comparisonです。
ODAC 12c Release 2で追加されたスキーマ比較はDatabase To Databaseだけだったのですが、今回追加されたOracle Database Project Version2(Beta)を利用すると、Database To Projectまたは、Project To Projectのスキーマ比較とスキーマの更新が利用できます。
サーバーエクスプローラーでの表の見え方が変わっています。関連表、、、まぁわかるけれど、、、
スキーマの比較を選択すると、データベース接続とプロジェクトを選択可能です。
古いデータベースプロジェクトには対象にできないようです。
Betaの悲しさか、サーバーエクスプローラーからデータベースプロジェクトへにインポートができないです。まぁスキーマ比較で入れれば良いんですけれど、、、
Betaが取れるのは何時かな。。。
Visual Studio 2013でセットアッププロジェクトをビルドする。
この頃お仕事でも本格的にVisual Studio 2013を使うようになってきた（遅！！）んだけれど、以前Visual Studioのセットアッププロジェクトを使ってセットアップを作っていたプロジェクトをロードするとセットアッププロジェクトが非推奨となりセットアップのビルドができなくなってしまった。
InfoQの記事「Visual Studioのセットアッププロジェクトが復活」を参照すると、Visual SutdioギャラリーでMicrosoft Visual Studio Installer Projectsをダウンロードしてインストールするか、「拡張機能と更新プログラム」からセットアップができるらしい。というかできた。
ODAC 12c Relase 3がリリース。Nuget版ODP.NETはもう少し後
Oracle Open World 2014で発表になった機能を実装し、ODAC12c Relase 3が正式リリースされたようです。ただし、このリリースと同時期に提供予定だったNugetの提供はもう少し後になるようです。
関連リソース
32-bit Oracle Data Access Components (ODAC) with Oracle Developer Tools for Visual Studio
http://www.oracle.com/technetwork/topics/dotnet/utilsoft-086879.html
Oracle Database Data Access Components Documentation 12c Release 3 (12.1.0.2.1)
既存のODT.NETのVisual Studioごとの共存が可能に？
インストールの途中にこのODT.NET(Visual Studioの拡張)をインストール済みのどのVisual Studioに適用するかという選択と、ODP.NETをマシンワイドレベルで構成するかという選択が可能になっていました。これまでのODT.NETは単一バージョンのみサポートされていましたが、今回のバージョンからはVisual Studioのバージョンごとに複数バージョンのODT.NETのインストールが可能になっているようです。
左はVisual Studio 2010+ODTwithODAC112012、右はVisual Studio 2013+ODTwithODAC121021
ODT.NETをマシンワイドレベルで構成しない場合、下記のダイアログの説明の通り、machine.configへの登録やGACへの登録が行われないのでアプリケーションで新しいバージョンのODP.NETを利用する場合web.configやapp.configへプロバイダの登録が必要になります（直にDLLを参照する場合はなくても動く)。
インストール後にmachine.configのsystem.dataセクションをみると、Oracle Data Provider for .NETのプロバイダー設定が以前のまま保持されていることを確認できます。既存のアプリケーションは以前のバージョンで開発したい場合などに便利ですね。
<system.data>
<DbProviderFactories>
<add name="Oracle Data Provider for .NET"
invariant="Oracle.DataAccess.Client"
description="Oracle Data Provider for .NET"
type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=4.112.1.2, Culture=neutral, PublicKeyToken=89b483f429c47342" />… 略 …
</DbProviderFactories>
</system.data>
直にDLLを参照するようなアプリケーションを作成する場合は、参照先に注意
マシンワイドレベルで構成しない場合、たしかに既存アプリケーションの参照は以前のものを利用しているようですが、Visual Studioのアセンブリの参照ダイアログからOracle.DataAccess.Clientを選択しようとすると、新しいバージョンしか出てこないので、以前のアセンブリを参照したい場合は参照ボタンからじかにDLLを選択する必要がありそうです。間違って新しいバージョンを参照してアプリを作ってしまうと実行環境で動かないとかいうことも…
＃これでやっとスキーマ比較を自分の普段使っているPCでも使えるようになった。
dotTrace 6.0, dotMemory 4.2のリモートエージェント
以前dotMemory4.0のリモートプロファイリングについて記事を書きましたが、dotTrace 6.0やdotMemory 4.2ではRemoteAgentの場所が変わっているので探してしまいました。
dotTrace5.*やdotMemory 4.0, 4.1の場合、各プログラムのインストーロフォルダーにRemoteAgentフォルダーがあるのでそれを利用します。例えば下記の場所に有るはずです。
- dotTrace 5.5: %ProgramFiles(x86)%\JetBrains\dotTrace\v5.5\Bin\Remote
- dotMemory 4.1: %ProgramFiles(x86)%\JetBrains\dotMemory\v4.1\Bin\Remote
- dotTrace 6.0やdotMemory4.2では、インストーラーが一新された影響で、プログラムの一式が%ProgramFiles(x86)%ではなく、％LOCALAPPDATA%にインストールされるようになったためこんなパスにZIPファイルとして配置されているはずです。
- dotTrace 6.0:%LOCALAPPDATA%\JetBrains\Installations\dotTrace01\RemoteAgent.zip
- dotMemory 4.2:%LOCALAPPDATA%\JetBrains\Installations\dotMemory01\RemoteAgent.zip
dotTraceやdotMemoryのコンソールからリモートエージェントに接続する方法はこれまでと変わりありません。dotTraceの場合、上記のZIPファイルへのショートカットのリンクがあるので、ここからもリモートエージェントのフォルダーを参照することができます。
プロファイル対象のプログラムを指定するUIと、プロファイリング中のスナップショットを取得したり破棄したりするUIがガラッと変わっていますね。
VB14で新しく増える構文で個人的に気に入っている構文ベスト3
VB TeamブログでVB14で採用される新しい構文について解説のエントリーが上がっています。
→ New Language Features in Visual Basic 14 (non-animated)
全体的に今までむず痒かった部分に手が入った感じですね。個人的にベスト３上げるとこの辺りが特に嬉しい！！
１位. 文字列の拡張書式構文
String.Formatの糖衣構文ですね。今までのString.Formatよりも可読性が上がって良い感じです。
まだPreviewには入っていないようです。（なんて訳せばいいんだろう。。。)
2位. 行継続中のコメント
これもなにげに嬉しい。VB10で行継続が明らかな場合は行継続子(_)が不要になりましたが、行継続中のコメントは相変わらず受け入れてくれなかったんですよね。
3位 ?.オペレーター
?.オペレーターは今までのVBから見るとちょっと驚く構文ですよね。記号っぽい構文はできるだけ採用してこなかったVBなのでびっくりしましたが、シンプルに書けるのは良い感じです。
まだ確認していないんだけれどこれらは糖衣構文なので、Visual Studio 14を使えばターゲーットフレームワークをVB14より低くしても問題ない機能ってことでいいのかな？
Visual Studio 2013 Update4 を入れたら、起動時に「AutoLoadPackagePackage パッケージは正しく読み込まれませんでした。」が出る。
つい先日出たVisual Studio 2013のUpdate4を入れたわけですが、Visual Studio起動時にこんなエラーが出るようになってしまいました。
—————————
Microsoft Visual Studio
—————————
‘AutoLoadPackagePackage’ パッケージは正しく読み込まれませんでした。構成の変更または別の拡張機能のインストールが原因で問題が発生している可能性があります。ファイル ‘C:\Users\xxxxxx\AppData\Roaming\Microsoft\VisualStudio\12.0\ActivityLog.xml’ を調べると、より詳細な情報を取得することができます。
引き続きこのエラー メッセージを表示しますか?
—————————
はい(Y) いいえ(N)
—————————
検索するとApache Cordova関連のアドオンを再インストールしたら治ったという記事を発見「‘Multi-Device Hybrid Apps for Visual Studio’のアンインストールに難儀した話」確かに入ってる。試しにCordovaのテンプレートから新しいプロジェクトを作るとこんなエラーが出る。これっぽいな。
—————————
Microsoft Visual Studio
—————————
The path "c:\users\sugiyama\documents\visual studio 2013\Projects\BlankCordovaApp1\BlankCordovaApp1" you have entered contains a space. Please select a location without a space when creating a Multi-Device Hybrid App Project.
—————————
OK
—————————
うまく行かなかったので更に検索したら、こんなKBを発見「Apache の Cordova CTP3.0 2013 の Visual Studio での Visual Studio のツールをインストールできません。」とりあえず書かれているコマンドを上から実行しています。
ちなみにこの画面で３時間ぐらい止まってました。一応アンインストール完了後は特に問題なく動いているようです。
ODT.NET 12.1.0.1.2のスキーマ比較はUIからのみ実行でき、対象はDBスキーマのみ
昨日の記事でODT.NETの12.1.0.1.2ではスキーマ比較ができるようになったってエントリーを書いたんですが、その後データベースプロジェクトとの比較と自動ビルドからのスキーマ比較を調べていたら、どうも今回のリリースは制限リリースで、データベースのスキーマ同士以外のスキーマ比較は対応していなそうです。
ODT.NETをインストールしたORACLE_HOMEにあるODACDocフォルダーにあるODTのreadmeのKnown Issuesを見るとこんな記述がありました。
Oracle Open World の.NET関連のスライドにある、ALM with Visual Studio: SQL and PL/SQL Development, Source Control, and Deploymentのスライド(45ページあたり)を見ても、データベースどうしの比較についてのみ触れられているので、このリリースに関してはデータベースプロジェクトとの比較はできないようです。また、当然ながらTFSの自動ビルドと組み合わせて自動配置ってのも難しそう。
うーん、今のところってことなんだよね？？（希望）。
ODT.NETのスキーマ比較を使ってみる
ちょっと前にでODAC 12c Relase2では、ついにOracleデータベースに対してVisual Studioからスキーマ比較ができるようになったってのを触れたと思いますが、どんな感じで使えるのか確認してみます。
→Oracle Data Provider for .NET 12.1のODP.NET管理対象ドライバ
ダウンロード/インストール
最初につまづきます。日本のOTNにあるODT.NETのリンクからはXCopy版のODP.NETしかリンクされておらず、ODT.NET(Visual Studioの拡張機能を含んだアーカイブ)が見当たらないので、本家のダウンロードリンクからダウンロードします。インストール自体はダウンロードしたアーカイブ中のSetupを実行してウィザードにしたがってインストールしていけばOKです。
32-bit Oracle Data Access Components (ODAC) with Oracle Developer Tools for Visual Studio
データベースに接続する
Visual Studioのサーバーエクスプローラーから、新規の接続を作成します。
スキーマ比較を行うデータベースへの接続情報を入力します。接続タイプでEZ接続を選択すると、簡易接続子を利用してTNSを利用しないで接続することもできます。ココでは比較元をDEV、比較先をSTGという名前で接続を作成します。
２つのデータベーススキーマを比較する
比較元のデータベースを選択し、コンテキストメニューからOracleスキーマの比較を選択します。
どのスキーマを比較対象にするかを選択し、OKボタンをクリックします。詳細ボタンを押すとスキーマ比較の比較対象を設定することができます。
比較が開始され、、、
比較結果が表示されます。比較結果は右上のフィルターアイコンから異なる定義のみなどに絞ることができます。また、SQLの更新ペインにはスキーマをソースと同じ定義に変更するためのDDLが出力されます。
まずはここまで。SQL Serverのデータベースプロジェクトでは随分前に同じことができていたので、OracleもやっとVisual Studioに対応したというところですね。そういえば、Oracle SQL Developerのデータベース差分は別にライセンスが必要だったってのを見たことがあるけれどこちらは特に触れられていないですね。→ Oracleのスキーマを比較するツール
アプリ起動に限ればクアントアプリは今のところx86ターゲットのほうが良いのか？
64bitOS上の.NET上で動作するプログラムの起動が遅くて我慢できないという報告を受けたので、調べた時のログです。
.NET 4.5現在では、アプリケーションの起動に限って言えば、ビルドターゲットをx86にしておいたほうが起動時間を短縮できます。起動後の動作速度を多少犠牲にしてもよいのであれば、アプリケーションのビルドターゲットをx86でビルドすることを検討してみましょう。
どこが遅いの？
とりあえず、遅いアプリをdotTraceで計測してみるとメインフォームのコンストラクター、またはInitializeComponentの呼び出しでふんづまっているようです。起動に20秒程度かかっているうち、フォームのコンストラクター呼び出しに17秒かかっていました。
顧客の情報を縦長の画面でサマリー表示していくような画面だったのでコントロールが多いのか？とも思ったんですが、グリッドが3つあるとはいえ、ラベルとテキストボックスなどのコントロール数は２００前後でそこまで重くなるとは考えにくいなーと思います。
うーん、とりあえずビルドターゲットをx86にしてみる。
そういえば、前もAny CPUからx86にして、WOW64にしたほうが起動が早くなったことがあったなーと思い、なんとなくビルドターゲットをAnyCPU → x86に変更して起動してみると、全体1秒以内に起動するようになり、問題があったコンストラクター部分も0.4秒で起動してきました。
あっ、そういえば、少し前に64bit OS上だとJITのパフォーマンスが悪くなるという記事を見たような。
- マイクロソフト、.NETアプリを数倍高速化する64ビット用JITコンパイラ「RyuJIT」をテクニカルプレビューで公開。由来は「龍神」(publickey)
- 64ビット（x64）環境でWindowsアプリケーションを実行した場合、初回起動に時間がかかる(GrapeCity)
64bitでも早いPCがあるらしい
気になることとしては、.NET Framework 4.5.1がインストールされていない環境では、早いという報告もありWebを検索するとMSDNフォーラムでこんなのが見つかりました。こちらも64bit環境ではJITが遅いことがあるみたいなことが書いてありますが、.NET Framework 4.5.1の何が問題かまでは言及されていないですね。
- Framework 4.5 64 bit speed issue
WOW64って実際にどのぐらいのハンディがあるんだろう
と思ってパフォーマンス測定をしてみようかと思ったんだけれど、画面→Webサービス→DB登録みたいな流れが主な業務アプリケーションで、どの程度有効なテストが作れるか疑問だったので、今回は影響が少なそうな奴から逐次実践投入をさせてみようかと思います。
- まぁ実際のところ、Visual Studioでデバックを行うときはWOW64上で動作してるんだから、パフォーマンスに限って言えばそこまで困ったことにはならないと思うんですよね。
Visual StudioでiOSアプリの開発ができる？？？
Xamarin enables iOS developers to write C# apps using Visual Studioと、そこでリンクされているIntroduction to Xamarin.iOS on Windowsをみると、Xamarinの新しい開発環境では、MacをビルドサーバーとしてVisual StudioでiOSアプリのコーディングができるようです。もちろんC#で。
MacOSなPCを一台も持っていないので、まだiOSのアプリ開発には手を出したことがないのですが、C#だけでなくVisual Studioが使えるのはかなり嬉しいですね。しかも、mono for androidのライセンスを持っていれば、クラスプラットフォーム開発も捗るし。それにVisual Studioが使えるので使い慣れたReShaperが使えるというおまけつき。
Installing Xamarin.iOS on Windowsに環境構築の流れとともに制限も記載されています。エミュレーターは付属しないため、デバックはiOS上でしか行えないとか、デザイナーは無いので、マックでInterface Builderで作ってねとかありますが、ちょっと可能性が広がりますね。
誰か、MacOS持っている人試してみてくれないかなー。
かるあのメモ on Wordpress 