C#で世界最速のMapperライブラリを作ってみた（AutoMapperなどよりも3倍-10倍ほど高速） - Qiita
概要 CodeProjectへ投稿した英語の記事を日本語に訳してQiitaでも共有します。 https://www.codeproject.com/Articles/5275388/HigLabo-Mapper-Creating-Fastest-Object-Mapper-in-t HigLaboMapperというオブジェクトマッパーを作ってみました。せっかく作るならということで世界最速を目標に作ってみました。 ExpressionTreeを使用して既存のマッパーライブラリであるAutoMapper,ExpressMapper,AgileMapper,FastMapper,Mapsterよりもはるかに高速な実装になっています。その結果、BenchmarkDotNetによるテスト結果で現在世界最速です。 また初期設定が不要で利用できるので無駄な設定コードを書く必要がありません。マッピングルー
AppVeyor で NuGet パッケージのデプロイを自動化 - しばやん雑記
非常に今更感がある内容なのと、Azure Pipelines の方が便利なんじゃないか疑惑もありますが、AppVeyor を使っているプロジェクトが多いので、やっと真面目に対応しました。 GitHub 上で新しく Release を作成すると、そのタグ名をバージョンにして NuGet パッケージを作成して、デプロイするという流れです。そしてタグ以外の場合はビルドはしますがパッケージは作成しません。 一部 NuGet とは関係ない部分もありますが、AppVeyor を使う場合に注意したい部分です。 Pull Request 作成時に 2 度ビルドされるのを防ぐ 普通に AppVeyor を使い始めると悩むのが、この PR 作成時の 2 度行われるビルドです。 ビルドが数秒で終わる場合ならまだマシですが、時間がかかる場合には最悪です。 イマイチ最適な解を見いだせなかったのですが、対象のブランチ
Home
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ライブラリプロジェクトをパッケージングしてNuGetサーバーに発行する
クロスプラットフォームで開発できる.NET Coreの基礎から開発実践までが学べる入門連載。6回目はクラスライブラリプロジェクトをNuGetパッケージとして参照できるように、作成と発行を行う。 ← 前回 連載 INDEX 次回 → NuGetパッケージとnuget.org NuGetパッケージ 前回はクラスライブラリプロジェクトをプロジェクト参照として別のプロジェクトから参照した。プロジェクト参照の場合、ソースコードを直接参照するため、ソースコードが必要であり、ビルドのたびにライブラリ側のビルドも行われる。ビルド後のバイナリのみを参照したい場合、ビルド成果物である.dllファイルのみを参照するという方法があるが、.dllファイルのみを参照すると、クラスライブラリ自身のバージョンや、クラスライブラリが必要とする別のライブラリのバージョンの管理を手動で行う必要がでてくる。 そこでNuGetパッ
NuGetパッケージのベストプラクティス - きよくらの備忘録
タイトルは若干釣りです。 Stack Overflowでこんなディスカッションを見つけました： Best practices with Nuget: Debug or Release? NuGet自体が一つのパッケージにReleasaeとDegubの両方のビルドを含めれたら一番いい…とも思いましたが、ビルド時にどちらを参照するか切り替える必要があるとか考えるとその仕組みをうまく提供するのが面倒な気もしますね。手動でビルドスクリプトなんかをカスタマイズすればできなくない気がしますが…。 とは言え、『ライブラリのソースにステップインしたい』だけなら何もDebugビルドは必要なく、昨日のエントリのようにReleaseビルドでシンボルパッケージを作成し、シンボルサーバにパブリッシュしておけば十分です。ですので、『ライブラリ自体のデバッグ』が必要な時以外の大抵の場合は以下で十分なんだとは思います。
アーティファクトリポジトリマネージャの比較 Nexus/Archiva/Artifactory - Qiita
開発元 Apache Software Foundation 対応リポジトリフォーマット Maven そのほか目玉機能 シンプルなMavenリポジトリマネージャーなので、これが一番基本になるのではないか。 基本情報 開発元: Sonatype Inc. http://www.sonatype.org/ OSS/PRO/PRO+などいろいろなエディションあり。 機能比較 対応リポジトリフォーマット Maven Rubygems NPM NuGet Yum P2 (PRO以降) OSGi Bundle Repository OBR (PRO以降) OSS版でもRubygems対応とか使えてよい。 そのほか目玉機能 LDAP連携 Atlassian Crowd連携 システムモニタリング 監査対応 REST API Sonarcube連携 などなど。ユーザーベースは一番大きい気がするので、それがメ
Windows に Sonatype Nexus で NuGet リポジトリサーバーを立ててみた | MiYABiS note.
お疲れ様です！NuGet パッケージを作成したら NuGet 公式に登録はしたくないけど社内や個人で管理したいときがあります。そんなときは NuGet リポジトリサーバーを立てます。ここでは Sonatype Nexus を使ってリポジトリサーバーを立ててみます。 Nexus のインストールダウンロードと配置下記より Windows 版をダウンロードします。（投稿時バージョン：3.5.1-02） Download Nexus Repository OSS ダウンロードしたファイルを適当なフォルダへ展開します。ここでは 「C:\Dev\Sonatype」とします。 サービス登録Windows キーを押下して cmd と入力後 Ctrl + Shift + Enter キーを押下して管理者：コマンドプロンプトを起動します。 コマンドプロンプトで下記のコマンドを実行しフォルダを移動します。 cd
NuGetパッケージのデバッグ - マイクロソフト系技術情報 Wiki
2024-06-11 GitHub Copilot 2024-06-04 GitHub GitHub Actions GitLab GitBucket 2024-05-28 Azure OpenAI Service AzureのAI系サービス Azure Databricks 2022-12-26 RecentDeleted 2024-05-28 Copilot FrontPage 開発ツール 2024-04-30 OSフリーズ 2024-01-24 性能問題のポイント 2023-12-14 ツール類（インデックス） 2023-12-13 ダウンロードのいろいろ 障害対応に使用するツールの一覧 開発支援ツール VBAは何故、最強EUCツールなのか？ 構成管理ツール OSSホスティング・サービス Git 2023-11-01 CAL 2023-09-19 Azure Container Re
C++プロジェクトでNuGetを使ってみようよ！（Vol. 2：パッケージ作成編） - Qiita
こんにちはー！ニアです。 今回は、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リポジトリでプライベートなシンボルサーバーを使う - きよくらの備忘録
NuGetには対象のライブラリの他に、デバッグシンボルとソースを含んだシンボルパッケージ(Symbol Package)を作成することが出来ます。公式のNuGetギャラリーで公開する場合、SymbolSource.orgにシンボルパッケージをデプロイすることで自動的にパッケージを関連付けてPDBファイルをダウンロードし、Visual Studioでソースコードにステップインを行うことができます。 これを『ローカルネットワーク上のプライベートリポジトリでも行えないか？』と思って調べてみると、NuGet.Serverを拡張したNuPeekというプロダクトがありました。 これを試してみたので、以下のステップでエントリにまとめてみたいと思います。 NuPeekの準備 ライブラリおよびシンボルパッケージの作成と配置 Visual Sutdioでの設定 パッケージの利用 ＜2013/04/09 23:
独自の NuGet フィードのホスティングの概要
パッケージをパブリックに利用できるようにする代わりに、組織やワークグループなど、制限された対象ユーザーのみにパッケージをリリースする必要がある可能性があります。 また、一部の会社では、開発者が使用する可能性があるサードパーティ製のライブラリを制限する必要がある場合があります。そのため、開発者に nuget.org ではなく、制限されたパッケージ ソースから引き出すように指示します。 このようなすべての目的のために、NuGet では次の方法でプライベート パッケージ ソースの設定をサポートします。 ローカル フィード: パッケージは適切なネットワーク ファイル共有に単純に配置され、nuget init と nuget add を使用して、階層フォルダー構造 (NuGet 3.3 以降) を作成するのが理想的です。 詳細については、「ローカル フィード」を参照してください。 NuGet.Ser
Home page - FuGet Gallery
fuget.org pro nuget package browsing This site is a nuget package browser combined with an API browser. The package browser uses the Nuget Gallery API to display all the packages in their index. The API browser combines the XML documentation and the metadata of the package's assemblies to help you explore and learn. Try the API search box to quickly find code, and use the code tab to see how the l
NuGet Gallery | Home
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
packages.config から project.json への移行
昨日、勉強会で少し話しましたが、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が何度も無関係のプロジェクトをビルドするのは、奴のせいかもしれない – NuGet編
まるで続きがあるかのようなラノベタイトルですが、一話完結です (;´Д｀) ものすごーく長い間、頭を悩ませてきた問題の一つが、先日ようやく判明したので共有しようと思います。 Visual Studio 2013（より前のバージョンも多分）で、比較的中規模～大規模なソリューション（沢山プロジェクトが含まれている）において、クリーンビルド後にも再びビルドが走って「イラっと」する問題です。 何度やっても発生する GitなどのSCMからソースコードだけを取得して、完全なクリーンビルドを行っても起きます。これが起きると、以後のビルドは「リビルド」の如く、依存関係上ビルド不要なものを次々とビルドしてしまうので、開発効率が極めて悪くなります。 「お前はバッチファイルでビルドしてるだろ」 と言いたくなります。 何故か、自分一人で開発している場合には発生しません。また、使用しているPCによって、起きたり起き
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Creating a Native (C++) NuGet Package for the Mako SDK - Global Graphics Software Shed
Push to Nexus 3 NuGet-repository from Jenkins CI without being asked for credentials
GitHub - warrenfalk/msbuild-protocol-buffers: MSBuild targets for automatic support of .proto files
nuget.config File Reference
SSSSLIDE
