2

私は SharePoint の初心者で、プロジェクトを開始する際に助けが必要です。クライアントに配信するパブリッシング サイトを開発する必要があります。標準の ASP.NET アプリケーションをデプロイするときと同じように、クライアントのデプロイ エクスペリエンスを可能な限り提供したいと考えています。Visual Studio 2008 を SharePoint 拡張機能と共に使用する予定で、おそらく WSPBuilder またはその他のツールを使用する予定です。プロジェクト全体の構造化にも助けが必要です。


1. 最小限のサイト定義を開発する
2. この定義からサイトを作成する。コードからこれを行うにはどうすればよいですか? SharePoint 機能を使用しますか? どのようにアクティベートすればよいですか？
3. サイトに必要なすべてのインフラストラクチャ (マスター ページ、レイアウト、コンテンツ タイプなど) を SharePoint 機能として開発します。

これは正しいですか、クライアントがワンクリックで完全なサイトを作成できるように、何らかのインストールスクリプトを作成できるように、これらすべての部分をどのように開発すればよいですか?

4

4 に答える 4

3

サイト定義は間違いなく複雑ですが、関連のない環境に展開する必要がある場合は非常に便利です。同じサーバー ファームにとどまっている場合は、サイト定義がやり過ぎかもしれません。ドメイン間を移動する場合 (つまり、テストと本番の場合、調べる価値があるかもしれません)。

サイト定義のもう1つの利点、特に。クライアントに提供する場合は、従来の成果物のように感じます。彼らは、カスタム サイトである一連のファイルを (できればソース管理に) 持っています。IT 部門は、SharePoint UI から作成された XML ファイルよりもはるかに温かい印象を受けると思います。

サイト定義のもう 1 つの利点は、サイトを構成するページをより細かく制御できることです。私見では、サイトテンプレートのサイト定義を介してマスターページとカスタム CSS を簡単に追加できます。

あなたが配信しようとしているサイトの「可動部分」は何ですか? その問いに答えることで、プロジェクトの構造をどう定義するかが決まると思います。

一般的に、あなたは正しい軌道に乗っていると思います。機能とソリューションは必須です。複雑なことをしようとしている場合、私は VSeWSS には近づかないでしょう。それはあなたがコントロールできないほど賢くしようとします。

とはいえ、それはあなたが何をしようとしているのかに大きく依存します。1 つのアセンブリを使用して GAC に展開するソリューションを構築し、vsewss でサポートされている機能のみを構築する場合は、問題ない可能性があります。

ただし、開発したい場合は、VSeWSS 機能フレームワークへのタイマー ジョブの配線が困難になるとします。また、ソリューションに複数のアセンブリが必要な場合。YMMV、しかし私はそれをジャンクして、より柔軟な解決策を見つけなければなりませんでした（こんにちはNANT）。

最終的に行う作業の多くは、XML 構成ファイルの作成とチェック、および再チェックです。MSDN のFeature Schemaリファレンス ページをブックマークしてください。これを読むのに多くの時間を費やすことになります。

最後に、はい、機能としてパッケージ化されたすべてのパーツがあれば、適切なインストール スクリプトを開発できるはずです。最終的に、スクリプトは、サイト構造の作成、ソリューションの追加と展開、および機能のアクティブ化に必要なSTSADM (いくつかの非常に優れた STSADM 拡張機能がここにあります) コマンドを呼び出す必要があります。バッチ ファイルから始めて、必要に応じて複雑にすることができます。

于 2009-02-25T15:33:30.037 に答える
2

言いたいことが300文字以上あるので、別の答えを追加します:(

RE: SharePoint ソリューション ジェネレーターです。繰り返しになりますが、マイレージはさまざまです。

SharePoint 開発者の最大の問題は、さまざまな構成ファイル全体ですべての "魔法の文字列" を管理することです。GUID と完全修飾アセンブリ名は、すべてをまとめるための唾液と接着剤であり、すべて理にかなっていますが、管理するのは非常に困難です。

現在のツールの一部はすべて、これらの管理の複雑さを軽減しようとしていますが、特定の方法で作業する必要があるため、ツールは適切な配管を挿入する方法を知っています.

SharePoint で多くの作業を行う予定がある場合は、自分で配管を管理することも学ぶ必要があります。前もって苦痛ですが、実際には利益をもたらします。

基本的に、ツールではなくプラットフォームの学習に時間を費やすことをお勧めします。プラットフォームを理解すると、ツールの使用がはるかに簡単になります。

これを 1 回限りのエンゲージメントとして行っていて、それをやりたいだけの場合は、あなたが言及したツールのいずれかを入手して、そのトリックを実行できると確信しています。

于 2009-02-25T16:24:18.807 に答える
2

個人的には、サイト定義を作成することが、私が構築したサイトにとって本当に役立つとは思いません。複雑な性質のため、設定が非常に難しい場合があります。

私が行っていることは、標準の発行サイトを使用してから、機能を使用して追加のコンポーネントを追加することです (SharePoint ソリューションを介して展開されます)。

フィーチャー ステープルを使用して、フィーチャーを発行サイトの作成に結び付けることができます。

また、デフォルトで作成されるワークフローをプログラムで変更する方法についてのブログ投稿も行いました。これには、コメントのオフに Feature Stapling の概念へのリンクもあります)。

次に、SharePoint ソリューション インストーラー ( http://www.codeplex.com/sharepointinstaller ) とバッチ ファイルを組み合わせて、コンポーネントをインストールします。すべての SharePoint データベース レベルのインストール用の SSI と、ファイル システム関連のバッチ ファイル。

于 2009-02-25T11:10:39.590 に答える