nuclex-shared-dotnet/Nuclex.Windows.Forms
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated deependency description

Browse Source
This commit is contained in:
cygon 2024-07-25 22:28:15 +02:00
parent 063099b0c9
commit 621fa1b818
2 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Dependencies.md
View File

@ -12,7 +12,7 @@ the following directory layout:
Nuclex.Windows.Forms/ <-- you are here
...
Nuclex.Support.Native/ <-- Git: nuclex-shared-dotnet/Nuclex.Support
Nuclex.Support/ <-- Git: nuclex-shared-dotnet/Nuclex.Support
...
third-party/
@ -24,13 +24,13 @@ repository (with `--recurse-submodules`).
The actual, direct requirements of the code to compile are:
* Nuclex.Support
* nunit (optional, if unit tests are built)
* nmock (optional, if unit tests are built)
* Nuclex.Support (project)
* nunit (NuGet package, optional, if unit tests are built)
* nmock (NuGet package, optional, if unit tests are built)
To Use this Library as a Binary
-------------------------------
* Nuclex.Windows.Forms.dll
* Nuclex.Support.dll
* Nuclex.Windows.Forms (project)
* Nuclex.Support (project)

2
Directory.Build.props
View File

@ -8,7 +8,7 @@
into the root 'obj' directory (instead of the intermediate directory below it),
causing one project to overwrite the other project's dependencies.
There won't be any buld warning, just suddenly one of the projects won't be able to
There won't be any build warning, just suddenly one of the projects won't be able to
access its dependencies and fail to build.
Why such a lackluster system was integrated at that level rather than just left to