メモ:Microsoft.Build.Tasks.Csc.ToolNameは、まだgmcs.batとかdmcs.batの記述が健在なので、それらがmcs.bat一本になったMono 2.11.2と一緒に使うとトラブルになる。
少なくとも一日はマシンの修理によるメーカー送りが避けられた。
さて、俺は懲りずにMonoDevelopのtrunkの独自ビルドに挑戦していた。(makefileではなくslnで)
ビルドはErrorなしで上手く行く。mono monodevelop.exeで確率でではあるが上手く起動する。
で何か、新しくソリューションを作ろうとするとコケた。
どうも、ビルドの度、generated.csが毎回生成されるようだ。internalが無駄についていたので書き換えても上書きされる。
CodeGenerator.GenerateProjectCode
とりあえず、ひたすらinternalのないPublicにしまくったら、その部分だけは治った。他の場所でまだトラブっているけど。
MonoDevelop.VBNetBinding.dllが読み込まれない原因、わかってしまえば非常に簡単だった。
https://github.com/mono/monodevelop/blob/master/main/src/addins/VBNetBinding/VBNetBinding.addin.xmlの2.9.5のところ少し前に2.9.6になったやつを全て2.9.4(もうMonoDevelop 2.9.5でちゃったけど、当時はMonoDevelop 2.9.4だったの！)に変えてあげればちゃんと認識される。
ビルド自体は、
前記事のように、mono上でvbncを起動しようとしたとき、出来上がるアセンブリにつくmscorlibは4.0のもの。(多分Microsoft.VisualBasic.dllが見つけられないのも同根なんじゃないかなあ)。まぁそれでも一応動くようだ。
とりあえず、以前のようにvbncで.NET 4.0向けのものをビルドできるように修正をかました。
あと、今回の本題だった「.NET 2.0向けのVBプロジェクトをビルドしようとしたとき、MS製のvbc.exeに対しても、存在しないオプション/optioninfer-を設定してしまう問題」を回避した。
環境: Mono 2.11.1 + MonoDevelop v2.9.4
Building Solution: Test1 (Debug|x86)
ビルド中: Test1 (Debug|x86)
Performing main compilation...
vbnc.bat "-out:C:\Users\kubota\Documents\Projects\Tomoyuki\Tests\Test1\Test1\Test1\bin\Debug\Test1.exe" -nologo -utf8output -quiet -debug:full -optionstrict- -optionexplicit+ -optioncompare:binary -optioninfer- -rootnamespace:Test1 -target:exe "C:\Users\kubota\Documents\Projects\Tomoyuki\Tests\Test1\Test1\Test1\Test.vb"
Warning: Option Strict Off will probably fail.
Error : VBNC2017: The library 'Microsoft.VisualBasic.dll' could not be found.
There were 1 errors and 0 warnings.
Compilation took 00:00:00.3250000
ビルド完了 -- エラー 1件, 警告 0件
---------------------- 完了 ----------------------
ビルド: エラー 1件, 警告 0件
以下、その他メモ。
- 以前.NET 4.0以降向けにVBプロジェクトをビルドできるように作ったMonoDevelop.VBNetBinding.dllは役立たず。何故なら、IsSourceCodeFileとかのシグネチャ(引数の型)が変更されているから。
- まず、本題の原因調査のため、MonoDevelop.VBNetBinding.dllを何度もビルドしつつ、入れ替えて動きを追おうと思った。途中、System.Func(TResult)が二重に定義されている等と言われて困惑するものの(何故か治った。解決した理由は正直わからないのだがw、二重定義の原因はなんとなく想像がつく。System.Funcは、.NET 3.5時代はSystem.Core.dllにあったのに、.NET 4.0ではmscorlibに移動していて、どうも対象フレームワークを.NET 4.0に合わせても.NET Framework 3.5時代のSystem.Core.dllを引きずったようなのだ。このプロジェクトはSystem.Coreに含まれる他のクラスも利用しているようだし、外せないんだよなあ)、何とかビルドしたアセンブリをMonoDevelopのアドイン用のディレクトリに入れても動かねーよ、なんでだよ、こんちくしょーとなったため、一応試してみようと思ってやってみたら前項の状況に気づいたというわけ。
- ごちゃごちゃしているからMonoDevelopのソースごと削除
- 当面は、「何故自前ビルドしたMonoDevelop.VBNetBinding.dllがオフィシャルビルドのMonoDevelop 2.9.4に認識されないか」の調査だなぁ…
- 結構面倒なんだよ(泣)？MonoDevelop.Coreとか色々必要になるから、このコンポーネントだけをビルドしたいだけなのに毎回MonoDevelopまるごとビルドしているから。で、何故か自前ビルドのMonoDevelopはMS謹製.NET 4.0で何故か動作しないし…orz
原因は不明ながら本題が解決した。vbnc.batをコマンドプロンプトで呼び出しても再現し、かつ、vbnc.exeを直接呼び出しても再現しないことから、vbnc.batの中身を見て、mono.exe上でvbnc.exeを実行しているのを確認。これをコマンドプロンプトで打ち、それだけでも問題が再現することを確認。vbnc.batで、monoを利用せず、vbnc.exeを直接起動するよう書き換えることでHello Worldをコンパイルできるようになった。再度削除。MS謹製 .NET Frameworkのライブラリを参照しているから解決しているように見えるだけで何の解決にもなってない。
結局、色々考えるのは諦めてmono上で動作させる際、vbnc.bat(.NET 4.0用)とvbnc2.bat(.NET 2.0用)でvbnc.exeにsdkpathを与えることにした。面倒だからまだやってないけど。というわけで、GetToolPathも書き換える予定
http://oshiete.goo.ne.jp/qa/7309347.html
List(Of T)にNothingを2つ追加したら要素数2だよね？ってなことを考えた。いや、まぁMSXML2.DOMDocument60にasyncプロパティ(デフォルト値はtrue)が存在し、まだ読み込まれていない部分はnullを返す、とかいうのを見てそう 思った。性能が低めなマシンがないと検証できない気がするんで回答は保留。"nullを返す状態"でそのノードがXPathにマッチするか自体がわからないような気もするし。
話は変わるが、色々Nothingに関わる実験をしてみようとして気になるコードを書く。構造体をIs演算子の左辺に置くとBC30020が出る。さて、System.Nullable(Of T)は構造体なんだが、vbcでは左辺においてもエラーがでない。vbncはエラーが出る。どうしたものか
折角だからvbncの例のstatic methodについて検証しようとして嵌る。現在のvbncはHashSet(Of T)を使っているようだが、こいつは、.NET 4.0以降のクラスだ。だが、Mono 2.10.8 + MonoDevelop 2.8.6.4の環境で、VBプロジェクトを作ると、そのプロジェクトのTargetFrameworkとして.NET 4.0を設定できない。MonoDevelop.VBNetBinding.GetSupportedClrVersionsの戻り値を書き換えてリビルドしファイルを置き換えたら治ったけど….NET 2.0のみのままにしておく必要性まだあるのかなあ？