WCFサービスは紺碧のクラウドとrunnigにデプロイされています。一部のdllにいくつかの変更があり、VMで更新したいが、通常の展開/再展開プロセスを実行したくない。
dllをapprootフォルダーとsiterootフォルダーに手動で対処することを考えています。それは機能しますか?将来VMが再起動したときに、新しいdllを取得しますか?
WCFサービスは紺碧のクラウドとrunnigにデプロイされています。一部のdllにいくつかの変更があり、VMで更新したいが、通常の展開/再展開プロセスを実行したくない。
dllをapprootフォルダーとsiterootフォルダーに手動で対処することを考えています。それは機能しますか?将来VMが再起動したときに、新しいdllを取得しますか?
あなたの質問に答えるために
ただし、サービスの開発中にいくつかのことをテストすることを計画している場合にのみ、これを行うことをお勧めします。
インスタンスに問題が発生した場合、Fabric Controllerがそのインスタンスを破棄して新しいインスタンスをデプロイすることを決定する可能性があるため、これを本番デプロイメントに使用することを計画しないでください(Windows Updateにも同じことが当てはまります)。この新しいインスタンスは、デプロイメントの初期状態(デプロイしたcspkgのコンテンツ)に戻ります。
開発の展開をさらに簡単にするために、WebロールでWebDeployをアクティブ化してVisual Studioから展開することもできます:VisualStudioを使用したWindowsAzure WebロールのWeb展開の有効化(これも実際の展開には使用しないでください。これは、次の場合にのみ使用します。 'いくつかのことをテストしています)。
注:Web配置は複数のインスタンスでは機能しません。
いいえ、
そして、これは行く方法ではありません。より動的にしたい場合は、Windows Azure AcceleratorforWebRolesのアプローチを採用する必要があります。もはやサポートおよび開発されたプロジェクトではありませんが、Blobストレージからアセンブリ(この場合はサイト全体)を動的にロードするための優れた基盤を提供します。