> これらは廃止されたらしくワーニングエラーが出てしまい、
ObsoleteAttribute 付きなので
警告BC40000 が通知されますが、廃止ではなく非推奨なだけで、一応使う事はできます。
ただし VB2015 の場合は、以下のようにして警告を抑制できます。
下記は、Format 関数の警告を抑制するためのラッパーメソッドです。
Module Module1
#Disable Warning BC40000, BC40008
Public Function Format(Expression As Object, Optional Style As String = "", Optional DayOfWeek As FirstDayOfWeek = FirstDayOfWeek.Sunday, Optional WeekOfYear As FirstWeekOfYear = FirstWeekOfYear.Jan1) As String
Return Global.Microsoft.VisualBasic.Compatibility.VB6.Support.Format(Expression, Style, DayOfWeek, WeekOfYear)
End Function
#Enable Warning BC40000, BC40008
End Module
上記を用意しておけば、警告なしで『 MsgBox(Format(Now, "yyyy(ge)/M/d")) 』を利用できます。
ただしこの策が使えるのは、VB2015 以降のみです。
VB2013 以下では #Disable Warning ディレクティブがサポートされていないため使えません。
仮に 2013 以下で Obsolete のコンパイル時警告を抑制する必要がある場合は、リフレクションを用いて回避するという策があります。
> 調べたところ、VB6.Formatを使わずにそれをやるには、
VB5 までのバージョンは、多言語対応のために、各国語版のランタイムを用意する必要があり、また、OS 設定に依存する部分も多かったという問題がありました（日本は比較的恵まれていましたが）。多言語対応の流れの中で、StrConv などは、VB6 で第三引数(LocaleID)が追加されるなどの対応がなされたものの、Format に関しては手付かずでした。
それが .NET では、System.Globalization 名前空間を用いる事で、その制限をかなり撤廃することができるようになっているわけで、その点は進化していると感じます。とはいえ今回の件も含め、個人的にはまだ十分では無いと感じていますけれども(ja-JP の "t" 書式とか何とかならないのか…)
とはいえ、Format 関数を使い続けたいか、と問われると否定派です。使いやすいかどうかでも重要ですが、多少使いにくくても、まずは要件を満たせるかどうかの方が自分にとっては重要なので。だからどうするべきだ、という案があるわけでは無いのですけれども。
> かなり面倒くさいことをしないとならないそうで…。
楽になったところもあれば、面倒になったところもあるのは確かですね。特に .NET 1.0 Beta 2 当時(2001年後半)は、情報も少なくて大変でした。
ただこの手の話は、定期的に繰り返される話題であるように思います。.NET 化の前、たとえば VB4 の 32bit 化の際にも互換性を問題視する声は挙がっていましたし、さらに遡れば、なんで VB は MML(Music Markup Language) をサポートしなかったんだ、なんていう意見もあったわけで。まぁ、MML については、限定的とはいえ奇跡の復活を遂げましたが。(Microsoft.SmallBasic.Library.Sound.PlayMusic メソッド)
> VB6.Formatのように、「簡単に」和暦出力ができるようではなさそうですね。
いずれにせよ、現時点で取りうる選択肢としては、
(1) ObsoleteAttribute に目をつぶって互換メソッドを使い続ける
(2) .NET 標準の書き方に順次置き換えていく
(3) それが和暦だけの問題なら、独自に変換関数を自作する
(4) 他のライブラリ――たとえば Oracle の和暦変換機能など――を流用する
ぐらいだと思います。自分は(2)が多いです。
どれが良いのかはケースバイケースなので、それぞれのメリットとデメリットを理解した上で判断してみてください。
ただ (1) に関しては、将来的に廃止されるでしょうし、個人的にはお奨めしていません。今後、新機能が追加されることも絶望的ですしね。
具体例を挙げれば、たとえば String.Format なら、新設されたタイムゾーン書式をサポートしますが、Format 関数では非対応といった点などです。VB6 時代に無かった書式を、互換メソッドに追加するわけにもいかないので仕方ないですけれどね…。
それとは別に、そもそも和暦変換を OS 依存にしておくことを不安視する声もあり、自分の周りでは (3)が採用されるケースをしばしば目にします。Windows 7 以降では和暦を自作できるようになったものの、この機能をサポートしているのは .NET Framework 4 以降の JapaneseCalender
クラスを使った場合であり、Format 関数は VBA も含めて非対応であるという事情も自作する理由の一つのようです。
> それにとって代わる代替案を提供すべきで、
代替案というなら、その一つが、Microsoft.VisualBasic.Compatibility.VB6.Support モジュールだと思いますよ。
あくまでも一時凌ぎのものなので、置き換えが推奨されてはいるというだけで。
その一方で、利用者側で代替策を講じることが困難な機能、たとえば StrConv などについては、互換機能であっても ObsoleteAttribute が付与されていませんね。
Format にしても StrConv にしても、OS 依存な所が強く、VB5 当時でさえ、Win9x と NT 系とで動作が違うなどの問題は未だに抱えていますし、どこまでを下位互換としてサポートを続けるかの線引きがあったのだと思いますが、利用者側としてみれば、それが Format の「和暦」だけの問題であるのなら、それを解決するための支援メソッドを開発者自身が自作した方が手っ取り早いですし、それを実装するのはそう難しくないと思います。
> そしてその代替案は利便性を損なうものであってはならない。
私自身は、必ずしもそうは思わないという立ち位置ですが、それが理想論だったとしても、現実は非情です。マイクロソフトによる仕様の取捨選択の判断が適切であったのかどうかは人によって見解が分かれるところでしょうけれども、利用者の誰もが満足するような代替案をすべてに対して提供する事は、現実問題として不可能ですから、どうしても限定的なサポートになってしまう部分は出てくるはずです。
今回の Format だけに限ればそれぐらい対応してよ、という声も個人的には分からなくないのですが、あちらを立てればこちらが立たず、というケースは常に生じます。その結果として、「私にとっては意味の無い事」のなすり付け合いになってしまい、不公平さや、あるいは予期していなかった事態を引き起こすといったことはあるわけで(.NET に限らず、Office VBA 界隈でもそういう事態を何度か経験しています…)、その時々で回避策を講じていくのが現実的かと。
とはいえ、使いにくい物は使いにくいと言った方が良いでしょう。今回の件に限らず、具体的な良案あるいは問題点がある場合、それを Visual Studio の「フィードバックの送信」機能で提案あるいは報告することをお奨めします。その意見に同調するユーザーがとても多くなれば、もしかしたらたとえば日本やアジア圏向けの追加ライブラリが別形態(たとえば
nuget)にて公開されるようなことも、運が良ければ起こるかもしれません。
なお、MSDN フォーラムは Microsoft に愚痴を語る場では無いので、ここで語るだけでは現場の声は伝わりません。ここでのやり取りは、基本的にはユーザー同士の意見交換の場であり、公式なサポートを期待する場所ではありませんから、将来バージョンへのフィードバックを期待するのであれば、本来のルートで声を届けるべきかと思います。
そういえば、KB418691 で知られる 旧 VB の Format 関数の動作仕様などは、日本の大手メーカー群からの声によって、仕様から不具合へと変更されて修正されたものだと聞いたことがあります。あくまでも噂程度ですし、もちろん国外からの声もあったのでしょうが、いずれにせよ、フィードバックは大事だと思いますよ。VB2005 で追加された My
なども現場の声から生まれた物らしいです（結果としては賛否両論だったわけですが）。
VB6.Format関数は、なぜ廃止された？
