ASP.NET Coreで作成したアプリのIISへの発行方法 - Qiita
この記事はASP.NET Advent Calendar 2016の23日目の記事です。 今年のAdvent Calendarの金曜担当していましたがとうとう今回がラストになりました。 私がこのAdvent Calendarに書いた前回の記事ではASP.NET CoreのアプリケーションをIIS上で動かすためのIISの設定について書きましたが、今回は実際にASP.NET CoreのアプリケーションをIISに発行するところまで書いていきます。 前回構築した環境があれば、今回の内容をすぐ試せるようになっているはずです。 ASP.NET Coreアプリケーションの作成 今回はVisual Studioからではなく、dotnet CLIからASP.NET Coreのアプリケーションを作成してみます。 アプリケーションを作成するパスに移動して管理者権限で以下のコマンドを実行します。 上記のコマンドを
index
.NET を使用して作成したアプリケーションは、2 つの異なるモードで発行できます。モードは、お客様のアプリをユーザーが実行する方法に影響します。 ご自分のアプリを "自己完結型" として発行すると、.NET ランタイムとライブラリ、さらにご自分のアプリケーションとその依存関係を含むアプリケーションが生成されます。 そのアプリケーションのユーザーは、.NET ランタイムがインストールされていないコンピューター上でそれを実行することができます。 ご自分のアプリを "フレームワーク依存" として発行すると、ご自分のアプリケーション自体とその依存関係のみを含むアプリケーションが生成されます。 そのアプリケーションのユーザーは、.NET ランタイムを個別にインストールする必要があります。 どちらの発行モードでも、既定ではプラットフォーム固有の実行可能ファイルが生成されます。 フレームワーク依存のア
.NET CLI を使用してアプリを公開する - .NET
公開の基礎 アプリを公開するときは、プロジェクト ファイルの設定 <TargetFramework> で既定のターゲット フレームワークを指定します。 任意の有効なターゲット フレームワーク モニカー (TFM) にターゲット フレームワークを変更できます。 たとえば、プロジェクトで <TargetFramework>net8.0</TargetFramework> を使用している場合は、.NET 8 をターゲットとするバイナリが作成されます。 この設定で指定されている TFM が、dotnet publish コマンドで使用される既定のターゲットになります。 複数のフレームワークをターゲットにしたい場合は、セミコロンで区切ることにより、<TargetFrameworks> の設定で複数の TFM 値を設定できます。 アプリをビルドするときは、ターゲット フレームワークごとにビルドが生成さ
ASP.NET Coreを動かすためのIISの構築方法 - Qiita
この記事はASP.NET Advent Calendar 2016の16日目の記事です。 今回はASP.NET CoreのアプリケーションをIISを通じて動かすためのIISの構築について意外と日本語の資料がないので書いていきます。 なお、記載されている内容は2016/12/16現在のもので、今後のASP.NET Coreやツール周りのアップデートによっては変わる可能性があります。 今回の構築環境は以下の通りです。 OS：Windows 10 Professional Build 10586 Webサーバー：IIS 10.0 前提として これまでのASP.NETはIISでホストされることが前提になっていてアプリケーションを実行するにはIIS(かIIS Express)が必要でしたが、ASP.NET CoreはIISに依存はしていなくて、アプリケーションを実行するにもIISが不要となっています
iis
インターネット インフォメーション サービス (IIS) は、Web アプリ (ASP.NET Core を含む) をホストするための、柔軟で安全で管理しやすい Web サーバーです。 サポートされているプラットフォーム 次のオペレーティング システムがサポートされています。 Windows 7 以降 Windows Server 2012 R2 以降 32 ビット (x86) または 64 ビット (x64) デプロイ用に発行されるアプリがサポートされています。 アプリが次の条件を満たさない限り、32 ビット (x86) .NET Core SDK を使う 32 ビット アプリをデプロイします: 64 ビット アプリ用の大規模な仮想メモリ アドレス空間が必要。 大規模な IIS スタック サイズが必要。 64 ビットのネイティブの依存関係がある。 ASP.NET Core モジュール/ホ
Jenkinsの自動デプロイにAnsibleを使ってみた - sometimes I laugh
ありがたいことに、以前のJenkins自動デプロイ記事がそれなりに多くの反応をいただきまして、冷静に見直してみたのですが、ちょっとデプロイ処理が雑だなと。 最近ではデプロイをやるにも、Capistranoやfabricなどのツールがあり、多様化するデプロイ要件に柔軟に対応できるような工夫が施されています。これらのツールを用いることで、シェルスクリプトで記述されたぐちゃぐちゃなオレオレデプロイを回避できたり、デプロイ失敗時のロールバックなどがしやすくなるメリットがあります。 現在開発しているアプリでは、git pullだけでデプロイできるようにしてあるので、前回の記事のようにJenkinsのジョブにシェルスクリプト直書きでもいいのですが、 デプロイ先の変更やスケールアウトに対応しにくい 認証鍵の場所をコマンドで直書きするのが、個人的にちょっと抵抗ある 書き方がスマートじゃない ←重要 という
構成管理 実践入門 第1章 構成管理入門 はじめに
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その１ メインライン コードライン編その２ コードラインポリシー コードライン編その３ プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その１ リリース管理 リリース編その２ 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか？ Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
Windows 10 Proの初期設定をAnsibleなどでやってみる。勝手に再起動とかありえないし - Qiita
前書き Windows 10 1607から使用できるようになったWindows Subsystem for Linux。 ベータ版ということもあり、特に入力周りに問題があり表示が崩れるためまだ常用するとは行かないが、それでもAnsibleを実行するくらいの役には十分立つ。 一方、Windows 10はOSに更新プログラムが当たると勝手に再起動することがあるのが非常に困りものである。 そこを何とかしたい、というのが当初のモチベーション。 それを含めたWindows 10 Pro用の初期設定をほとんど自動でやってしまおうというのがこの記事の目的である。 よくあるMacの初期設定をAnsibleで、ってやつのWindows版を書きたかったという話でもある。 本文 注意事項 これはWindows 10 1607で実施しているが、将来この記事を書き直すことがあれば将来のバージョンに対応したものに書き
実録！AnsiblevsChef-solo
2016/01/27 リクルートテクノロジーズ社内勉強会での、北野の資料になりますRead less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
