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

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

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

Re[4]: .Net5、.Net6の仕様問題


(過去ログ 172 を表示中)

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

■98919 / inTopicNo.1)  .Net5、.Net6の仕様問題
  
□投稿者/ 大谷刑部 (162回)-(2022/01/19(Wed) 11:15:40)

分類:[雑談] 

Winformsで.Net4.X系より激烈に不便になった件、MSは直す気ないんでしょうかね?
去年の初頭あたりに、調べてたときは、VS2019の方の問題かもと疑ってましたが、どうやら2019,2022でも、プロジェクト新規作成時にテンプレートをFormアプリ(.NetFramework)を選択すれば、ほぼほぼ2017の時と同様の利便性で画面設計できるようです。

デザイナーは「待て」のメッセージが出ていつまでたっても表示されないし、DataGridviewはプロパティーWindowや↓からの右くりからデータソースを追加しようとするとほぼ100%エラーになってハングします。
デザイナーをコードで開いて、定義を追加すればできるにはできますが、それじゃRadツールの意味がないですよね?
まるでHTMLの画面設計をテキストエディタでしてるみたいな感じになってきます。

それとImports(VBの場合)を追加しても、データソースを追加したときに自動生成したソースがコンパイルエラーになるのもどうかと思います。
まあこれは.Net5以降の問題ではなく、前身の.Net CoreがNuGetで「インストール」しない限りだめって仕様をそのままにしてるみたいですが。
プロジェクトと関連付けるだけなのに「インストール」というのに非常に違和感があります。

あくまで雑談なので、直感的に皆様が感じるところを記載してもらうと助かります。

引用返信 編集キー/
■98921 / inTopicNo.2)  Re[1]: .Net5、.Net6の仕様問題
□投稿者/ くま (122回)-(2022/01/20(Thu) 04:58:29)
半年前Visual Studio 2019でVB.net .net framework 4.8 Windowsフォームで開発してたのを
今年に入ってVisual Studio 2021に変更したらソフトの安定性はダウンしましたね

プロパティの表示がされなくなったり、コード変更がおかしかったり
あとアンドゥが正常に作動しなかったり...。
いまさら前のバージョンってわけにもいかないし確かに困っていますね。

あと謎のImportsが利かない現象とか
なぜかvisualスタイルが無効になっている場合があるとか
(Application.EnableVisualStyles()の話見つけるまで3日かかった)
開発環境が悪くなるのはちょっと辛いです。
引用返信 編集キー/
■98928 / inTopicNo.3)  Re[2]: .Net5、.Net6の仕様問題
□投稿者/ 大谷刑部 (163回)-(2022/01/20(Thu) 11:19:26)



No98921 (くま さん) に返信
> 半年前Visual Studio 2019でVB.net .net framework 4.8 Windowsフォームで開発してたのを
> 今年に入ってVisual Studio 2021に変更したらソフトの安定性はダウンしましたね
>
> プロパティの表示がされなくなったり、コード変更がおかしかったり
> あとアンドゥが正常に作動しなかったり...。
> いまさら前のバージョンってわけにもいかないし確かに困っていますね。

そうでもないんじゃないです?
2022でも .net framework 4.8 Windowsフォームは選択できるはずなので、あまりに不具合がひどいようならターゲットフレームワークは戻す方がむしろ安全な気はします。

>
> あと謎のImportsが利かない現象とか

これは多分私も起こった現象と同じですね。おそらくは該当の参照設定をするために、プロジェクトにNuGetで「インストール」で解決はすると思います。
それが.Net Core系の仕様ということみたいです。

> なぜかvisualスタイルが無効になっている場合があるとか
> (Application.EnableVisualStyles()の話見つけるまで3日かかった)
> 開発環境が悪くなるのはちょっと辛いです。

実業務で使うとなると特に感じますよね?
何か今回に関しては、そもそも不具合が多いというのが世間的にも浸透してるのか、
とりあえず.net6でやってみた的な情報を公開してる人も少ない気がします。
そうなると、ノウハウも地力で調べない限りたまらないし、確実に開発効率落ちますよね?
お気持ちよくわかります。


引用返信 編集キー/
■98937 / inTopicNo.4)  Re[3]: .Net5、.Net6の仕様問題
□投稿者/ くま (128回)-(2022/01/21(Fri) 10:59:47)
やられた...
今度はツールボックスに設定してるのにボタンとか表示されなくなった。
(別スレのとは違うプロジェクトですよ。)

Visual Studio 2019入れて10日でVisual Studio 2021が公開になったのでどうしようか迷ったんです

今年に入って心機一転で!ってVisual Studio 2021にしたのにこの仕打ち...
入れなおししかないかな...。
引用返信 編集キー/
■98938 / inTopicNo.5)  Re[4]: .Net5、.Net6の仕様問題
□投稿者/ 魔界の仮面弁士 (3282回)-(2022/01/21(Fri) 11:03:20)
2022/01/21(Fri) 11:53:04 編集(投稿者)

No98937 (くま さん) に返信
> Visual Studio 2019入れて10日でVisual Studio 2021が公開になったのでどうしようか迷ったんです
> 今年に入って心機一転で!ってVisual Studio 2021にしたのにこの仕打ち...
VS2021 なんて製品はありませんよ?
VS2019 の次は VS2022 です。


> 入れなおししかないかな...。
Visual Studio は複数のバージョンを共存インストールすることもできます。
ストレージ容量に余裕があれば、新旧両方を入れておいた方が移行しやすいかと。

[VS2017] と [VS2019] と [VS2022] …といった
メジャーバージョンの異なるもの同士の共存だけではなく、
[VS2022 17.0.5] と [VS2022 17.1.0 Preview 2.0] といった、
メジャーバージョンが同一の組み合わせであっても共存できます。
引用返信 編集キー/
■98948 / inTopicNo.6)  Re[5]: .Net5、.Net6の仕様問題
□投稿者/ 大谷刑部 (164回)-(2022/01/21(Fri) 15:30:59)
尚、DatagridViewに関しては散々な感じですが、Webview2コントロールに関してはむしろ改善されている気がしました。
前はコントロール起動時にWait処理を入れないとほぼ動かなかったのですが、VS2022+.Net6では入れなくても起動しました。
根本原因は環境によるので入れといた方がいいのいいんでしょうがね。
引用返信 編集キー/
■98949 / inTopicNo.7)  Re[5]: .Net5、.Net6の仕様問題
□投稿者/ くま (129回)-(2022/01/21(Fri) 15:50:05)
寝ないとダメですね...誤字が...

あれから起きた現象と対応を一応書いておきます
まずVS2022で作成いていたWindowsフォームにツールバーを設定ボタン複数を割り当てて表示されている事を確認
クリック時の処理等書き込んで確認して同プロジェクト内別のフォームを作成(何度かデバック実行しています)

動作確認で前のフォームを実行して開くとツールバーのボタン等一式が表示されない現象となる。
対応1. [Debug][Release]のクリア(クリーンや実フォルダの削除)
変化なし

対応2. コントロールの削除
フォームファイルのバックアップをした後
対応2.a. 編集画面でコントロールを再作成
編集中になぜかエラーになり編集できない。
対応2.b. Designer.vbで対象コントロールをコメント化
こちらもエラーになり編集実行できない

対応3. フォームの再作成
対応3.a. フォームを一度プロジェクトから除外実行後再度参加させる
参加させても表示されず。
対応3.b. フォームを再度新規で作成。Designer.vbの編集でコントロールをコピー
やはり表示されない。
対応3.c. フォームを再度新規で作成。再度編集画面で作成しなおす
状態復帰。ただし前後でDesigner.vb等確認しても変更点は見つけられず。

こんな感じです。





引用返信 編集キー/
■98950 / inTopicNo.8)  Re[6]: .Net5、.Net6の仕様問題
□投稿者/ くま (130回)-(2022/01/21(Fri) 16:01:49)
バージョン違いでインストールなのですが、
VSのソフト自体は良いのですが、元からあったプロジェクトファイル100以上が既にVS2022に変換されています。
一応Microsoftの話では大丈夫との事ですが
https://docs.microsoft.com/ja-jp/visualstudio/install/install-visual-studio-versions-side-by-side?view=vs-2022
https://docs.microsoft.com/ja-jp/visualstudio/porting/port-migrate-and-upgrade-visual-studio-projects?view=vs-2022
本当に大丈夫か確認するだけでも大変で...
バックアップしてから修正かけたプロジェクトもあるんでどうしたものかと。
単に文字列の差分だけでは治らない現象を経験したんで...

あとお客様への説明ですよね。
エビデンスがそろわないと旧バージョンへ戻す事を了承もらえないですね...。

見た目ほとんど同じなのに、こうも安定性がないとは...
引用返信 編集キー/
■98952 / inTopicNo.9)  Re[7]: .Net5、.Net6の仕様問題
□投稿者/ 大谷刑部 (165回)-(2022/01/21(Fri) 16:26:58)
No98950 (くま さん) に返信
> バージョン違いでインストールなのですが、
> VSのソフト自体は良いのですが、元からあったプロジェクトファイル100以上が既にVS2022に変換されています。
> 一応Microsoftの話では大丈夫との事ですが
> https://docs.microsoft.com/ja-jp/visualstudio/install/install-visual-studio-versions-side-by-side?view=vs-2022
> https://docs.microsoft.com/ja-jp/visualstudio/porting/port-migrate-and-upgrade-visual-studio-projects?view=vs-2022
> 本当に大丈夫か確認するだけでも大変で...

それは私もやって、共存自体はしてるのは確認してるので大丈夫だと思います。
ソリューション/プロジェクトファイルを開くときにダブルクリックでなく、右クリ→開くでどのバージョンのVSで開くかを選択すれば、新しいバージョン固有のものを使ってなければどのバージョンでも開きます。
ただし、ターゲットフレームワークがそれぞれのバージョンでサポートしてるものという条件は付くと思いますが。

> あとお客様への説明ですよね。
> エビデンスがそろわないと旧バージョンへ戻す事を了承もらえないですね...。

多分それが一番大変でしょうね。

>
> 見た目ほとんど同じなのに、こうも安定性がないとは...

4.xでGUI的に便利になってた機能は軒並みアウトな印象はあります。
Windowsの機能をフル活用した機能をきちんと動かすよりも、他プラットホームでの汎用性を優先してるイメージはどうしてもぬぐえないので。
やっぱり、いくらなんでもプロパティーウィンドウからデータソースを追加しようとしたらハングしてVS自体が異常終了したりするのが頻発するのは、MSがどんなに言い訳しようとバグだと思います。
Webview2は逆にGUI開発としてはイマイチの感じで、ブラウザー側に挙動を任せてる感じが強いので、逆に安定したのかもしれません。
直感的な感想で、もちろんエビデンスをもった根拠はないですが。

引用返信 編集キー/
■98959 / inTopicNo.10)  Re[1]: .Net5、.Net6の仕様問題
□投稿者/ Azulean (1222回)-(2022/01/21(Fri) 22:56:46)
No98919 (大谷刑部 さん) に返信
> Winformsで.Net4.X系より激烈に不便になった件、MSは直す気ないんでしょうかね?

.NET Framework の後継ではないですし、オープンソースなので WinForms のクラスライブラリに由来する話なら修正の pull request を投げることもできます。
(それなりに気合いは必要ですが)


> デザイナーは「待て」のメッセージが出ていつまでたっても表示されないし、DataGridviewはプロパティーWindowや↓からの右くりからデータソースを追加しようとするとほぼ100%エラーになってハングします。
> デザイナーをコードで開いて、定義を追加すればできるにはできますが、それじゃRadツールの意味がないですよね?
> まるでHTMLの画面設計をテキストエディタでしてるみたいな感じになってきます。

Visual Studio 本体自体は現在も .NET Framework なので、.NET Core/5/6 の WinForms デザイナは別プロセスとの連携で実装されています。
このため、同一プロセス前提で動いていた、過去の資産がいろいろと動かないというものはあるかもしれません。


-----
個人的には、.NET Framework 4.x の WinForms の旧来のノリをそのまま .NET 5/6 にぶち込むのはお勧めしません。
WPF でがっつり仕切り直すとか、.NET Framework 4.8/.NET 6 のマルチターゲットプロジェクトでいつでも切り戻しできるようにするとか、思想転換を進められる風土、資産でないと難しいでしょう。
引用返信 編集キー/
■98961 / inTopicNo.11)  Re[2]: .Net5、.Net6の仕様問題
□投稿者/ 大谷刑部 (166回)-(2022/01/24(Mon) 11:20:04)


No98959 (Azulean さん) に返信
> ■No98919 (大谷刑部 さん) に返信
>>Winformsで.Net4.X系より激烈に不便になった件、MSは直す気ないんでしょうかね?
>
> .NET Framework の後継ではないですし、オープンソースなので WinForms のクラスライブラリに由来する話なら修正の pull request を投げることもできます。
> (それなりに気合いは必要ですが)
>

MSの本音は基本は.Net Core系に移行してほしいが、かといって、.NetFrameworkで開発した資産が存在する限り、無視するわけにもいかず、
バージョンアップは4.8で止めるが、サポートは今のところ続けてるという状態なんでしょうね。
C#が出たての頃のVBの扱いに似ている状況な気がします。


>>デザイナーは「待て」のメッセージが出ていつまでたっても表示されないし、DataGridviewはプロパティーWindowや↓からの右くりからデータソースを追加しようとするとほぼ100%エラーになってハングします。
>>デザイナーをコードで開いて、定義を追加すればできるにはできますが、それじゃRadツールの意味がないですよね?
>>まるでHTMLの画面設計をテキストエディタでしてるみたいな感じになってきます。
>
> Visual Studio 本体自体は現在も .NET Framework なので、.NET Core/5/6 の WinForms デザイナは別プロセスとの連携で実装されています。
> このため、同一プロセス前提で動いていた、過去の資産がいろいろと動かないというものはあるかもしれません。

なるほど。別プロセスになってるなら確かに現象の原因として理解はできますね。
ただ、それはテンプレートとして存在してて、使い物にならないとアプリ開発者に思われたらMSにとってもマイナスが気がするんですけどね。

>
>
> -----
> 個人的には、.NET Framework 4.x の WinForms の旧来のノリをそのまま .NET 5/6 にぶち込むのはお勧めしません。
> WPF でがっつり仕切り直すとか、.NET Framework 4.8/.NET 6 のマルチターゲットプロジェクトでいつでも切り戻しできるようにするとか、思想転換を進められる風土、資産でないと難しいでしょう。

逆に言うと、WinFormsベースの画面設計を維持するなら、.NET Framework 4.xで当面開発し続ける方がベターということにはなりますよね?
同じ.Netとついていても似て非なるもので、基本的に互換性なしというのは試しにいろいろやってみている段階でそう思います。
引用返信 編集キー/
■98962 / inTopicNo.12)  Re[3]: .Net5、.Net6の仕様問題
□投稿者/ Azulean (1223回)-(2022/01/24(Mon) 11:55:46)
No98961 (大谷刑部 さん) に返信
> MSの本音は基本は.Net Core系に移行してほしいが、かといって、.NetFrameworkで開発した資産が存在する限り、無視するわけにもいかず、
> バージョンアップは4.8で止めるが、サポートは今のところ続けてるという状態なんでしょうね。

.NET Framework は今も Windows の一部として提供されている実態もあるので、サポートは当面続くとされています。
ただし、HTTP3 など、最新技術への追従はありませんので、テクノロジーの進化とともに、使えなくなっていく場面が出てくるはずです。


> C#が出たての頃のVBの扱いに似ている状況な気がします。

VB6 ランタイムが未だ同梱されているあたり、切るに切れない状況ではあるでしょうね。
なお、VB.NET は引き続きサポートされていますが、言語の拡張はもう行わないと宣言されているので、VB 系言語は静かにフェードアウトしていくことになります。
(C# で足されたような便利な機能は足されないし、言語拡張が前提の新機能も VB.NET では使えなくなる)


> ただ、それはテンプレートとして存在してて、使い物にならないとアプリ開発者に思われたらMSにとってもマイナスが気がするんですけどね。

この辺は見せ方が下手だとは思いますね。
入り口から分けるのではなく、ウィザード形式でどういう特徴があるか示唆すればまだ受け入れやすいんでしょうけれども。


> 逆に言うと、WinFormsベースの画面設計を維持するなら、.NET Framework 4.xで当面開発し続ける方がベターということにはなりますよね?
> 同じ.Netとついていても似て非なるもので、基本的に互換性なしというのは試しにいろいろやってみている段階でそう思います。

Microsoft としては、「今後の .NET 開発は .NET 5/6/7... を推奨し、.NET Framework 4.x での新規開発は推奨しない」といスタンスです。
それでもなお、.NET Framework 4.8 を選ぶのは開発者の自由ですが、Microsoft が望んでいる姿からは外れていることは自覚して、リスクを背負う必要はあります。

ゆえに、「ベター」とは言い切れません。
各々がメリット・デメリット・リスクを考慮して決定するものですので、どれがベターかはなんとも言えません。
引用返信 編集キー/
■98963 / inTopicNo.13)  Re[4]: .Net5、.Net6の仕様問題
□投稿者/ 大谷刑部 (167回)-(2022/01/24(Mon) 15:37:15)
No98962 (Azulean さん) に返信
> ■No98961 (大谷刑部 さん) に返信
>>MSの本音は基本は.Net Core系に移行してほしいが、かといって、.NetFrameworkで開発した資産が存在する限り、無視するわけにもいかず、
>>バージョンアップは4.8で止めるが、サポートは今のところ続けてるという状態なんでしょうね。
>
> .NET Framework は今も Windows の一部として提供されている実態もあるので、サポートは当面続くとされています。
> ただし、HTTP3 など、最新技術への追従はありませんので、テクノロジーの進化とともに、使えなくなっていく場面が出てくるはずです。

この辺は確かにおっしゃる通りかと思います。VB6→.Netの時も、下手にVB6がバクも少なく安定したシステムを作りやすい言語ではあったので、
.Netへの移行が遅れたという印象はあります。
現実問題として私も5〜6年前までVB6の仕事してましたもの。
そしてなぜかエンドユーザーが作ったシステムにも1万ステップクラスの巨大なVB6のクラスDLLが現実に動いていて、誰も触れないとかいう場面も見ました。
その時のお客さんに聞いたら、それを作った人だけがプロでないのにやたらプログラムに詳しく、つくったものの、その人が辞めてしまい、社内の人で触れる人がいなくなったそうです。
当然Visul Studio6がお客さんの環境に入ってないので、ソースの全てをテキストエディタで見る必要があるという恐ろしい状態です。
.NetFrameworkが便利で設計しやすいからといつまでもそれで開発してたら、いざ本当に使えなくなった時の作り直しの工数は莫大になりますね。


>>C#が出たての頃のVBの扱いに似ている状況な気がします。
>
> VB6 ランタイムが未だ同梱されているあたり、切るに切れない状況ではあるでしょうね。
> なお、VB.NET は引き続きサポートされていますが、言語の拡張はもう行わないと宣言されているので、VB 系言語は静かにフェードアウトしていくことになります。
> (C# で足されたような便利な機能は足されないし、言語拡張が前提の新機能も VB.NET では使えなくなる)

この点はMSの公表してる方針をまだ信用しきれてないです。
.Netが最初に出たときの噂では、VBを使う人なんて数年で居なくなり、みんなC#に移行するだろうくらいにMSは考えていて、実際、一時的にVBのシェアもVBプログラマーの人口も減りましたが、
いざVB6システムのマイグレーションとなった時にはVB.netを選択する人が大半で、VBが盛り返し、MSがC#に取り込もうとした人材はJAVAに取られてしまった印象があります。
MSのユーザーの動向で平気で方針転換しますし、今言ってることがそのまま100%未来の姿かというとそうじゃない気がしてます。
Win10が最後のOSになるはずが、普通に11発売されちゃいましたしーーーー。(しかもバグだらけで評判悪いという)

>>ただ、それはテンプレートとして存在してて、使い物にならないとアプリ開発者に思われたらMSにとってもマイナスが気がするんですけどね。
>
> この辺は見せ方が下手だとは思いますね。
> 入り口から分けるのではなく、ウィザード形式でどういう特徴があるか示唆すればまだ受け入れやすいんでしょうけれども。

せめてそういう状態にはしてほしいですね。

>>逆に言うと、WinFormsベースの画面設計を維持するなら、.NET Framework 4.xで当面開発し続ける方がベターということにはなりますよね?
>>同じ.Netとついていても似て非なるもので、基本的に互換性なしというのは試しにいろいろやってみている段階でそう思います。
>
> Microsoft としては、「今後の .NET 開発は .NET 5/6/7... を推奨し、.NET Framework 4.x での新規開発は推奨しない」といスタンスです。
> それでもなお、.NET Framework 4.8 を選ぶのは開発者の自由ですが、Microsoft が望んでいる姿からは外れていることは自覚して、リスクを背負う必要はあります。
>
> ゆえに、「ベター」とは言い切れません。
> 各々がメリット・デメリット・リスクを考慮して決定するものですので、どれがベターかはなんとも言えません。

そうですね。あくまで各開発現場のポリシー次第でベターが決まるので、ベストはどこにも存在しない。


ご意見ありがとうございました。
直感的な話で書ける範囲の議論は出尽くした感があるのでこのスレとしては解決済みにしようかと思います。

ーーーーーーーーーーーーーーーーーーー
くまさん

現在進行形の現場の問題の続きを議論したい/未解決の件を質問したい場合は、別スレをお建てになっていただければと思います。

解決済み
引用返信 編集キー/


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

このトピックに書きこむ

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

管理者用

- Child Tree -