C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[4]: 元号対応2


(過去ログ 137 を表示中)

[トピック内 6 記事 (1 - 6 表示)]  << 0 >>

■80721 / inTopicNo.1)  元号対応2
  
□投稿者/ 真田昌幸 (21回)-(2016/08/05(Fri) 15:24:06)

分類:[.NET 全般] 

今のところ元号対応は、

JAVA:マスタ参照に決定
VB:マスタ参照 or カレンダークラス参照

の方向で話は進んでます。

ただ問題が一つあり、現状の最終のコンパイルが.NetFramework3.5なんです。
要するにカレンダークラスがレジストリ管理になる前・・・・。

そこでお聞きしたいのは、.NetFrameworkバージョンアップのリスクについてです。

どんなものが考えられるでしょうか?
根本機能が変わったのは2.0の印象があるため、
3.5→4.0 or 4.5はそこまでインパクトは無いように思っていますが、
どうでしょうか?

ちなみに、oleaut32.dll参照は元号に関してはやめるように改修予定です。



引用返信 編集キー/
■80722 / inTopicNo.2)  Re[1]: 元号対応2
□投稿者/ shu (898回)-(2016/08/05(Fri) 15:53:32)
No80721 (真田昌幸 さん) に返信

各クラスの
廃止されたメンバーとか廃止予定のメンバーを
使用していなければFrameWork変更後、コンパイル位で
終わりますが、使っている場合警告とかエラーが出るので
それらを修正していく必要があります。
引用返信 編集キー/
■80724 / inTopicNo.3)  Re[1]: 元号対応2
□投稿者/ 魔界の仮面弁士 (801回)-(2016/08/05(Fri) 19:59:49)
No80721 (真田昌幸 さん) に返信
> 3.5→4.0 or 4.5はそこまでインパクトは無いように思っていますが、

インパクトという点では、セキュリティルール(CAS など)と
非同期対応(Task クラス)などが大きいところですかね。

今回のケースでは恐らく気にしなくて良いでしょうけれども。



> ちなみに、oleaut32.dll参照は元号に関してはやめるように改修予定です。

それが懸命かと思います。

ちなみに、CLR2 から CLR4 への移行に際しては、
COM の呼び出しに関しても仕様変更があったりします。


[.NET Framework 4 への移行に関する問題]
https://msdn.microsoft.com/ja-jp/library/ee941656%28vs.100%29.aspx
https://msdn.microsoft.com/en-us/library/ee941656%28vs.100%29.aspx

上記によれば、オートメーションサーバーに対する
『LCID』 パラメーターについて、下記のような変更点が記載されています。

》 CLR はアンマネージ COM ベースのアプリケーションに対する
》 LCID パラメーターに現在のカルチャを渡さなくなりました。
》 代わりに、カルチャとして 1033 (en-us) が渡されます。

》To be consistent with expected behavior
》in automation server settings,
》the CLR no longer passes the current culture
》for the LCID parameter to unmanaged COM-based applications.
》Instead, it passes 1033 (en-us) for the culture.



LCID パラメーターというのは、あまり聞き慣れないかもしれませんが、
Excel のタイプイブラリを見ると、Workbooks.Open や Workbook.Save など、
[in, lcid] long lcid な引数を持つメンバーが多数存在しています。

※この引数は、VBA や VB.NET のオブジェクト ブラウザーでは確認できませんが、
 OLE/COM オブジェクト ビューアーで調べることができます。


この LCID の仕様変更が原因で、実行する VB バージョンによって
下記のような差異が生じることになります。


(1) バージョン 2013 の Excel で新規ブックを作成し、
  セルA1の表示形式を
    分類:通貨
    小数点以下の桁数:0
    記号:\
    負の数の表示形式:\-1,234(黒)
  に設定し、それを "C:\TEMP\TestData.xlsx" として保存します。


(2) 下記のコードを、VB2008 および VB2015 にて実行します。
  Microsoft.Office.Interop.Excel を参照設定しておいてください。

Module Module1
  Sub Main()
    'LCID を変更しながら、ファイルを上書き保存していく
    For Each cultureName In New String() {Nothing, "en-US", "ja-JP", "de-DE"}
      If cultureName Is Nothing Then
        cultureName = "Default"
      Else
        Thread.CurrentThread.CurrentCulture = New CultureInfo(cultureName)
      End If

      Dim ci As New CultureInfo(cultureName)
      Thread.CurrentThread.CurrentCulture = ci

      '作業前にコピーしておく
      Dim filePath As String = "C:\TEMP\" & cultureName & ".xlsx"
      FileCopy("C:\TEMP\TestData.xlsx", filePath)

      Dim app As New Excel.Application()
      app.Visible = True
      Dim books As Excel.Workbooks = app.Workbooks
      Dim books As Excel.Workbooks = app.Workbooks
      Dim book As Excel.Workbook = Nothing
      Try
        book = books.Open(filePath)
        book.Save()
        book.Close()
      Catch ex As Exception
        MsgBox(ex.Message, MsgBoxStyle.SystemModal)
      Finally
        If book IsNot Nothing Then
          Marshal.ReleaseComObject(book)
        End If
      End Try
      Marshal.ReleaseComObject(books)
      app.Quit()
      Marshal.ReleaseComObject(app)
    Next
  End Sub
End Module


------------
参照設定に用いる Microsoft.Office.Interop.Excel は
バージョン 15.0.0.0 のアセンブリで試してみました。
当方環境では、下記のような結果となります。

【VB2008 .NET 2.0 Console App】

"TestData.xlsx" の書式は、通貨 "\-1,234"(黒) です。無加工。
"Default.xlsx" の書式は、ユーザー定義 "\#,##0;-\#,##0" に変化しました。
"en-US.xlsx" の書式は、通貨 "(\1,234)" に変化しました。
"ja-JP.xlsx" の書式は、ユーザー定義 "\#,##0;-\#,##0" に変化しました。
"de-DE.xlsx" は Workbooks.Open が失敗したため、書式が変更されていません。


【VB2015 .NET 4.6.1 Console App】

"TestData.xlsx" の書式は、通貨 "\-1,234"(黒) です。無加工。
"Default.xlsx" の書式は、通貨 "(\1,234)" に変化しました。
"en-US.xlsx" の書式は、通貨 "(\1,234)" に変化しました。
"ja-JP.xlsx" の書式は、通貨 "(\1,234)" に変化しました。
"de-DE.xlsx" の書式は、通貨 "(\1,234)" に変化しました。エラーにはなりません。


本事象について、下記も参照して見て下さい。
https://social.msdn.microsoft.com/Forums/ja-JP/4e454fcc-93f8-4372-98ac-9a65fb3e38e3/excelexcel?forum=csharpgeneralja


なお、LCID に 1033 (en-us) が渡されるようになったのは、
COM オートメーションに限定した事象のようです。

念のために P/Invoke な呼び出し(Declare または DllImportAttribute)も
テストしてみましたが、こちらは CLR2 でも CLR4 でも、
LCIDConversionAttribute での指定に対して
Thread.CurrentThread.CurrentCulture.LCID がそのまま渡されており、
1033 (en-us) に変化する事象は確認できませんでした。
引用返信 編集キー/
■80747 / inTopicNo.4)  Re[2]: 元号対応2
□投稿者/ 真田昌幸 (22回)-(2016/08/08(Mon) 11:56:28)
ご回答ありがとうございます。

No80724 (魔界の仮面弁士 さん) に返信
> ■No80721 (真田昌幸 さん) に返信
>>3.5→4.0 or 4.5はそこまでインパクトは無いように思っていますが、
>
> インパクトという点では、セキュリティルール(CAS など)と
> 非同期対応(Task クラス)などが大きいところですかね。
>
> 今回のケースでは恐らく気にしなくて良いでしょうけれども。
>

ユーザー環境は
Win7SP1
.NetFrameworkは3.5(.1?)、4.0の共存のようです。

OSにSP1をあててて、4.0で止めてる理由はよくわかりませんが。

今のところ元号対応は、
3.5のまま、Javaと同じくマスタ参照にするか、
4.5.2まで上げて、カレンダークラス参照にするかの
2者択一になりそうです。
(前者の可能性が高?)

4.6へのバージョンアップはおそらくWin10対応までお預け。

4.x系のマイナーバージョンが多いのが若干気になりますが、
不具合とか結構出ているのでしょうか?





引用返信 編集キー/
■80749 / inTopicNo.5)  Re[3]: 元号対応2
□投稿者/ 魔界の仮面弁士 (806回)-(2016/08/08(Mon) 14:19:11)
No80747 (真田昌幸 さん) に返信
> Win7SP1
> .NetFrameworkは3.5(.1?)、4.0の共存のようです。

Windows 7 に標準搭載されている .NET Framework 3.5.1 というのは、
「.NET Framework 3.5 SP1 + 累積パッチ」に相当するバージョンです。
Windows 7 なら 2020/01/15 までがサポート期限となります。

ちなみに、Windows 7 以外の OS のサポート期限は、
Windows Vista は 2017/04/12 まで
Windows 8.1 は 2023/01/11 まで(Windows 8 は期限切れ)
Windows 10 では 2025/01/15 までですね。


> OSにSP1をあててて、4.0で止めてる理由はよくわかりませんが。

.NET Framework 4/4.5/4.5.1 のサポートは
今年の1月13日をもって既に終了していますので、
本来は 4.5 系の最終版である 4.5.2 か、あるいは
4.6 系に移行していてしかるべきではありますね。

結局はリスク判断と天秤にかけることになるのでしょうけれど、
.NET Framework の 4 と 4.5.x は共存できず、いわゆる
インプレース更新となりますので、導入済みのアプリケーションが
「4 では検証したが、4.5 以降での検証を行っていない」場合には、
あえて 4 で止めておくという選択肢もあるのだと思います。
それが望ましい事かどうかは別として。


> 3.5のまま、Javaと同じくマスタ参照にするか、
> 4.5.2まで上げて、カレンダークラス参照にするかの
> 2者択一になりそうです。
> (前者の可能性が高?)

良いんじゃ無いでしょうか。既に Java 実装があるのなら、
足並みを揃えておいた方が、メンテナンスもしやすいでしょうしね。

あるいは、そうしたシステム依存度を減らすために、参照するマスターを
Oracle にするのか PostgreSQL にするのか SQL Server にするのか
config にするのか csv にするのか .NET 内部実装を用いるのかなど、
後から差し替えられるような抽象設計なクラス実装にしているケースも
目にしたことがあります。最終的には案件次第ですね。


> 4.x系のマイナーバージョンが多いのが若干気になりますが、

参考までに、CLR2 世代のマイナーバージョンを挙げておきます。

OS プリインストール版、単体リリース版、製品同梱版などといった
細かい違いまでは調べ切れていませんが:

2005/11/07 2.0.50727.42   …… 2.0 RTM 
2006/11/06 3.0.4506.30    …… 3.0
2007/01/30 2.0.50727.312  …… 2.0 RTM (NT 6.0)
2007/07/10 2.0.50727.832  …… 2.0 (KB928365)
2007/11/19 3.5.21022.8    …… 3.5
 同上   3.0.4506.648   …… 3.0 SP1
 同上   2.0.50727.1433 …… 2.0 SP1
2008/02/04 2.0.50727.1434 …… 2.0 SP1 (NT6.0 SP1)
2008/08/12 3.5.30729.1    …… 3.5 SP1
 同上   3.0.6920.1453  …… 3.0 SP2
 同上   3.0.4506.2123  …… 3.0 SP2
 同上   3.0.4203.2152  …… 3.0 SP2
 同上   2.0.50727.3053 …… 2.0 SP2
2009/01/26 2.0.50727.3074 …… 2.0 SP2 (KB959209)
2009/04/29 3.0.6920.4000  …… 3.0 SP2 (NT6.0 SP2)
 同上   3.0.4506.4037  …… 3.0 SP2 (NT6.0 SP2)
 同上   2.0.50727.4016 …… 2.0 SP2 (NT6.0 SP2)
2009/07/13 3.5.30729.4926 …… 3.5 SP1 (NT6.1)
 同上   3.0.6920.4902  …… 3.0 SP2 (NT6.1)
 同上   3.0.4506.4926  …… 3.0 SP2 (NT6.1)
 同上   3.0.4203.4926  …… 3.0 SP2 (NT6.1)
 同上   2.0.50727.4927 …… 2.0 SP2 (NT6.1)
2009/10/14 2.0.50727.4200 …… 2.0 SP2 (NT6.0 SP2, KB974378)
 同上   2.0.50727.3603 …… 2.0 SP2 (KB974378)
 同上   2.0.50727.1873 …… 2.0 SP1 (NT6.0 SP1, KB974378)
 同上   2.0.50727.1003 …… 2.0 (NT6.0, KB974378)
2010/08/11 2.0.50727.4206 …… 2.0 SP2 (NT6.0 SP2, KB2265906, .NET 3.5 SP1)
 同上   2.0.50727.3615 …… 2.0 SP2 (KB2265906, .NET 3.5 SP1)
 同上   2.0.50727.1882 …… 2.0 SP1 (KB2265906, .NET 3.5)
2010/11/19 3.5.30729.5420 …… 3.5 SP1 (NT6.1 SP1)
 同上   3.0.6920.5011  …… 3.0 SP2 (NT6.1 SP1)
 同上   3.0.4506.5420  …… 3.0 SP2 (NT6.1 SP1)
 同上   3.0.4203.5420  …… 3.0 SP2 (NT6.1 SP1)



> 不具合とか結構出ているのでしょうか?

というよりも、開発サイクルが変更されているということですね。

CLR4 世代では Service Pack という形ではリリースされていませんし、
4.5 世代、4.6 世代という括りの中で、バージョン管理されていった
結果なのだと思います。

4.5  …… 2012/08/15
4.5.1 …… 2013/10/12
4.5.2 …… 2014/05/05

4.6  …… 2015/07/20
4.6.1 …… 2015/11/30
4.6.2 …… 現在プレビュー版


Windows 10 も、メインリリースとしては
 ★TH1: Version 10.0 (ビルド 10240) 初期版(2015/07/29)
 ★TH2: Version 1511 (ビルド 10586.x) 2015年11月版(2015/11/12 November Update)
 ★RS1: Version 1607 (ビルド 14393.x) 2016年7月版(2016/08/02 Anniversary Update)
となりますが、Insider-Preview の方々はもっと頻繁に更新されますので
それと同じようなものかと思います。
(Long Term Servicing Branch なユーザーは、未だに 10240 ですが)

引用返信 編集キー/
■80782 / inTopicNo.6)  Re[4]: 元号対応2
□投稿者/ 真田昌幸 (24回)-(2016/08/10(Wed) 16:19:48)
No80749 (魔界の仮面弁士 さん) に返信
>>OSにSP1をあててて、4.0で止めてる理由はよくわかりませんが。
>
> .NET Framework 4/4.5/4.5.1 のサポートは
> 今年の1月13日をもって既に終了していますので、
> 本来は 4.5 系の最終版である 4.5.2 か、あるいは
> 4.6 系に移行していてしかるべきではありますね。
>
> 結局はリスク判断と天秤にかけることになるのでしょうけれど、
> .NET Framework の 4 と 4.5.x は共存できず、いわゆる
> インプレース更新となりますので、導入済みのアプリケーションが
> 「4 では検証したが、4.5 以降での検証を行っていない」場合には、
> あえて 4 で止めておくという選択肢もあるのだと思います。
> それが望ましい事かどうかは別として。

内部システムのWindowsアプリケーションと言いながら、
日本全国にある各支部にインストールする構成らしいので、
(ここまで多いとWebアプリの方が本来はいい気もしますが)
100台近くの端末のWidows Updateを動かして4.5.2 or 4.6.1にUpdateする手間と
(普段スタンドアロンなので、自動Updateはしない)
検証工数が予算的に取れないため、
.NET Framework3.5で開発する方針となりました。
(サポートが切れている4で開発するのもNG)

よって、必然的に

>>3.5のまま、Javaと同じくマスタ参照にするか、
>>4.5.2まで上げて、カレンダークラス参照にするかの
>>2者択一になりそうです。
>>(前者の可能性が高?)

は前者となります。

> 良いんじゃ無いでしょうか。既に Java 実装があるのなら、
> 足並みを揃えておいた方が、メンテナンスもしやすいでしょうしね。

Javaもこれから実装です。
こちらはやり方バラバラなのをマスタ参照に統一するイメージ。
Javaのカレンダークラスは、MSのように、明確な対応方針が出ていないため、
VBより先に却下になってます。

具体的にいうと、元請のリーダーがJAVAに詳しく、
私がVBに詳しいので、似たようなクラスをそれぞれ設計して、
オフショアに開発を渡す感じです。

> あるいは、そうしたシステム依存度を減らすために、参照するマスターを
> Oracle にするのか PostgreSQL にするのか SQL Server にするのか
> config にするのか csv にするのか .NET 内部実装を用いるのかなど、
> 後から差し替えられるような抽象設計なクラス実装にしているケースも
> 目にしたことがあります。最終的には案件次第ですね。

残念ながら、データソースは政治的事情により以上のどれでもありません。
また、既存機能はODBC経由のため、こちらもODBC経由になりそうです・・・。
これは将来的な変更を視野に入れ、接続文字列を外だし(iniファイル等)にして、
変更できるときに工数を減らす布石を打つことくらいですね。
できることは。

>>不具合とか結構出ているのでしょうか?
>
> というよりも、開発サイクルが変更されているということですね。
>
> CLR4 世代では Service Pack という形ではリリースされていませんし、
> 4.5 世代、4.6 世代という括りの中で、バージョン管理されていった
> 結果なのだと思います。
>
> 4.5  …… 2012/08/15
> 4.5.1 …… 2013/10/12
> 4.5.2 …… 2014/05/05
>
> 4.6  …… 2015/07/20
> 4.6.1 …… 2015/11/30
> 4.6.2 …… 現在プレビュー版

4.6.2は8/2に正式版リリースされたらしいですね。
調査環境で、Windows Updateをかけてみたら、
4.6.1のチェックを外して4.5.2をインストールしても、
次の再起動でまた4.6.1のチェックがついてしまう設定になってますね。
相変わらずMSはやることが強引ですね。
非表示にしない限り必ず4.6.1までインストールされる結果になります。

うがった見方すぎるかもしれませんが、
間接的にWin10へのアップグレードを促そうとする作戦?
と勘ぐってしまいます。



引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -