#概要 CodeProjectへ投稿した英語の記事を日本語に訳してQiitaでも共有します。 https://www.codeproject.com/Articles/5275388/HigLabo-Mapper-Creating-Fastest-Object-Mapper-in-t HigLaboMapperというオブジェクトマッパーを作ってみました。せっかく作るならということで世界最速を目標に作ってみました。 ExpressionTreeを使用して既存のマッパーライブラリであるAutoMapper,ExpressMapper,AgileMapper,FastMapper,Mapsterよりもはるかに高速な実装になっています。その結果、BenchmarkDotNetによるテスト結果で現在世界最速です。 また初期設定が不要で利用できるので無駄な設定コードを書く必要がありません。マッピングル
非常に今更感がある内容なのと、Azure Pipelines の方が便利なんじゃないか疑惑もありますが、AppVeyor を使っているプロジェクトが多いので、やっと真面目に対応しました。 GitHub 上で新しく Release を作成すると、そのタグ名をバージョンにして NuGet パッケージを作成して、デプロイするという流れです。そしてタグ以外の場合はビルドはしますがパッケージは作成しません。 一部 NuGet とは関係ない部分もありますが、AppVeyor を使う場合に注意したい部分です。 Pull Request 作成時に 2 度ビルドされるのを防ぐ 普通に AppVeyor を使い始めると悩むのが、この PR 作成時の 2 度行われるビルドです。 ビルドが数秒で終わる場合ならまだマシですが、時間がかかる場合には最悪です。 イマイチ最適な解を見いだせなかったのですが、対象のブランチ
Package update automation is necessary because .NET developers are bad at applying NuGet package updates. We want to make it easier to find and apply these changes. To increase visibility of package updates, and decrease cycle time. Why do we deploy code changes frequently but seldom update NuGet packages? In Continuous delivery, we know that there is a vicious cycle of "deploys are infrequent and
クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。6回目はクラスライブラリプロジェクトをNuGetパッケージとして参照できるように、作成と発行を行う。 ← 前回 連載 INDEX 次回 → NuGetパッケージとnuget.org NuGetパッケージ 前回はクラスライブラリプロジェクトをプロジェクト参照として別のプロジェクトから参照した。プロジェクト参照の場合、ソースコードを直接参照するため、ソースコードが必要であり、ビルドのたびにライブラリ側のビルドも行われる。ビルド後のバイナリのみを参照したい場合、ビルド成果物である.dllファイルのみを参照するという方法があるが、.dllファイルのみを参照すると、クラスライブラリ自身のバージョンや、クラスライブラリが必要とする別のライブラリのバージョンの管理を手動で行う必要がでてくる。 そこでNuGetパッ
タイトルは若干釣りです。 Stack Overflowでこんなディスカッションを見つけました： Best practices with Nuget: Debug or Release? NuGet自体が一つのパッケージにReleasaeとDegubの両方のビルドを含めれたら一番いい…とも思いましたが、ビルド時にどちらを参照するか切り替える必要があるとか考えるとその仕組みをうまく提供するのが面倒な気もしますね。手動でビルドスクリプトなんかをカスタマイズすればできなくない気がしますが…。 とは言え、『ライブラリのソースにステップインしたい』だけなら何もDebugビルドは必要なく、昨日のエントリのようにReleaseビルドでシンボルパッケージを作成し、シンボルサーバにパブリッシュしておけば十分です。ですので、『ライブラリ自体のデバッグ』が必要な時以外の大抵の場合は以下で十分なんだとは思います。
アーティファクトリポジトリマネージャというのは、成果物の管理や配布に使ったり、外部ライブラリのプロキシとして動かしたりするツールの総称。説明はこちらをどうぞ リポジトリ管理ツール：Artifactoryの紹介 - @ikikko のはてなブログ。 有名どころ３つについて調べたのでまとめてみた。 調べてみると、RubygemsとかPyPIとかNPMとかNuGetにも対応してて賢い。こういうの使うとライブラリが取得できなくて悲しい思いをするのが減ってよいと思う。 Python書く人間としてはArtifactoryを推したいかな。 Archiva 開発元 Apache Software Foundation 対応リポジトリフォーマット Maven そのほか目玉機能 シンプルなMavenリポジトリマネージャーなので、これが一番基本になるのではないか。 Nexus 基本情報 開発元: Sonatyp
お疲れ様です！NuGet パッケージを作成したら NuGet 公式に登録はしたくないけど社内や個人で管理したいときがあります。そんなときは NuGet リポジトリサーバーを立てます。ここでは Sonatype Nexus を使ってリポジトリサーバーを立ててみます。 Nexus のインストールダウンロードと配置下記より Windows 版をダウンロードします。（投稿時バージョン：3.5.1-02） Download Nexus Repository OSS ダウンロードしたファイルを適当なフォルダへ展開します。ここでは 「C:\Dev\Sonatype」とします。 サービス登録Windows キーを押下して cmd と入力後 Ctrl + Shift + Enter キーを押下して管理者：コマンドプロンプトを起動します。 コマンドプロンプトで下記のコマンドを実行しフォルダを移動します。 cd
2025-04-23 .NET 8への移行 2025-04-22 Excelアドイン .NET 5への移行 2025-04-21 .NET Core .NET 10 .NET 8 .NET 5 .NET Coreバージョンアップ .NET 6 .NET 6への移行 .NET 10への移行 2025-04-18 Microsoft Office Visual Basic for Applications (VBA) Office Script Visual Basic Office 365 Access、Access VBA Excel、Excel VBA 2025-04-04 事務作業系 性能問題のポイント 2025-04-01 GitHub資格Copilot 2025-03-31 GitHub Copilot模擬試験 2025-03-30 GitHub Copilot MS Learn
こんにちはー！ニアです。 今回は、C++プロジェクトでNuGetを使ってみようよ！（Vol. 1：パッケージ導入編） の続編で、C++用のNuGetパッケージを作成する基本的な方法について紹介していきます。 1. C++用のNuGetパッケージを作成するために必要なもの C++向けのNuGetパッケージに必要なものは以下の4点です。但し、プロパティシートは必要に応じて用意します。 NuGetパッケージに入れたいライブラリ Nuspecファイル プロパティシート nuget.exe Nuspecファイルとは、パッケージの情報やパッケージに含めるファイルの場所などが定義されたXMLファイルで、拡張子は「.nuspec」です。 プロパティシートとは、C++のプロジェクトの設定するためのXMLファイルで、拡張子は「.props」または「.targets」です。 nuget.exeはNuGetパッケ
NuGetには対象のライブラリの他に、デバッグシンボルとソースを含んだシンボルパッケージ(Symbol Package)を作成することが出来ます。公式のNuGetギャラリーで公開する場合、SymbolSource.orgにシンボルパッケージをデプロイすることで自動的にパッケージを関連付けてPDBファイルをダウンロードし、Visual Studioでソースコードにステップインを行うことができます。 これを『ローカルネットワーク上のプライベートリポジトリでも行えないか？』と思って調べてみると、NuGet.Serverを拡張したNuPeekというプロダクトがありました。 これを試してみたので、以下のステップでエントリにまとめてみたいと思います。 NuPeekの準備 ライブラリおよびシンボルパッケージの作成と配置 Visual Sutdioでの設定 パッケージの利用 ＜2013/04/09 23:
注意 このページにアクセスするには、承認が必要です。 サインインまたはディレクトリの変更を試すことができます。 このページにアクセスするには、承認が必要です。 ディレクトリの変更を試すことができます。 パッケージを公開する代わりに、組織やワークグループなどの限られた対象ユーザーのみにパッケージをリリースできます。 さらに、一部の企業では、開発者が使用できるサード パーティ製ライブラリを制限し、それらの開発者に対して、nuget.org ではなく限られたパッケージ ソースから描画するように指示する場合があります。 このような目的のために、NuGet では次の方法でプライベート パッケージ ソースの設定がサポートされています。 ローカル フィード: パッケージは単に適切なネットワーク ファイル共有に配置されます。理想的には、nuget init と nuget add を使用して階層フォルダー
What is NuGet? NuGet is the package manager for .NET. The NuGet client tools provide the ability to produce and consume packages. The NuGet Gallery is the central package repository used by all package authors and consumers. Learn New to NuGet? Start with a walkthrough showing how NuGet powers your .NET development. Explore Browse the thousands of packages that developers like you have created and
昨日、勉強会で少し話しましたが、Visual Studio 2015で、csproj/vbproj 中での NuGet パッケージ管理が少し楽になります。 正確には、7/20にリリースされた状態の Visual Studio 2015だけじゃなくて、その後Windows 10に合わせて出たVisual Studio Tools for Windowsが必要。(どうも、その後Visual Studio 2015のバイナリも更新されていて、最新のやつならVisual Studio 2015に含まれているっぽい(もしかしたらCommunityだけかも？))。 移行ツール書きました。 既存のプロジェクトを新しい仕組みに対応させるには、現状だと何の移行ツールも提供されていなくて、自前で色々と作業が必要になります。 個人的に試してみた結果、機械作業で、プログラムを使って自動化できそうだったので、作った
まるで続きがあるかのようなラノベタイトルですが、一話完結です (;´Д｀) ものすごーく長い間、頭を悩ませてきた問題の一つが、先日ようやく判明したので共有しようと思います。 Visual Studio 2013（より前のバージョンも多分）で、比較的中規模～大規模なソリューション（沢山プロジェクトが含まれている）において、クリーンビルド後にも再びビルドが走って「イラっと」する問題です。 何度やっても発生する GitなどのSCMからソースコードだけを取得して、完全なクリーンビルドを行っても起きます。これが起きると、以後のビルドは「リビルド」の如く、依存関係上ビルド不要なものを次々とビルドしてしまうので、開発効率が極めて悪くなります。 「お前はバッチファイルでビルドしてるだろ」 と言いたくなります。 何故か、自分一人で開発している場合には発生しません。また、使用しているPCによって、起きたり起き
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く