4

DNN用のモジュールをバージョン2から開発してきましたが、当時は、自分の環境でモジュールを開発したときにモジュールを簡単に実行でき、モジュールをDLLとして簡単にデプロイできました。バージョン4がリリースされ、(Webアプリケーションソリューションではなく)Webサイトソリューションを使用したとき。何かが失われたようです。テスト環境で開発を続け、変更を加えるとすぐに変更を確認できますが、リリースするのは頭痛の種になりました。

私は主に1つのサイトの開発を行っています。特に、変更を加えた後、メインサイトへのモジュールのFTP展開を使用しています。

複数の開発者がモジュールで作業できるように、適切な環境を設定したいと思います。

ソース管理に何かを追加するとき、人々は通常、すべてのDNNをソース管理に入れて、ソリューション全体を機能させることができますか、それともモジュールと各人が独自の開発DNN環境をセットアップする必要がありますか?

より多くの人がモジュールプロジェクトに取り組むことができるように、モジュールプロジェクトの整理を開始したいと思います。これを行うことと、これらの変更をライブサイトに展開することの両方で、いくつかのベストプラクティスに少し迷いました。

4

2 に答える 2

3

これについては、私のブログ サイトmitchelsellers.comに詳細なブログ投稿がいくつかあります。

私は個人的に WAP 開発モデルを使用しており、クライアントのコアを変更していないため、DNN ソリューションやコア ファイルをソース管理にチェックしていません。複数の人と作業する場合、各人に同様の環境を作成し、個々のプロジェクトのそれぞれで作業することができます。個別のデータベースとコードを使用して開発環境を完全に分離することもあれば、共有開発者と作業することもあります。データベースを使用して、開発モジュールのインストールの問題を解決します。

WAP モデルでは、ビルド後のイベントを使用してプロジェクト ビルドでインストール パッケージを動的に作成する方法を使用し、パッケージが発生することを検証するために使用するテスト インストールを行います。デバッグは、プロセスへのアタッチを介して行われます。

于 2008-09-17T20:31:51.487 に答える
2

参考資料が必要な場合は、ミッチェルの本をお勧めします - Professional Dotnetnuke Module Programming by Wrox Module Programming - Michel Sellers

于 2009-04-22T21:41:06.780 に答える