Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fixed a few typos in the readme #161

Merged
merged 2 commits into from
May 24, 2022
Merged

Fixed a few typos in the readme #161

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6b4a2da
Fix typo
AntonC9018 Dec 6, 2021
ce4557e
Update readme.md
AntonC9018 Dec 9, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions readme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,7 +123,7 @@ b. **FrameworkSpecific**: *true*/*false*, determines whether the project's targe
c. **TargetPath**: optional PackFolder-relative path for the item. If not provided, the relative path of the item in the project (or its *Link* metadata) is used.


When an item specifies *FrameworkSpecific=true*, the project's target framework is added to the final package path, such as `lib\netstandard2.0\My.dll`. Since the package folder itself typically determines whether it contains framework-specific files or not, the *FrameworkSpecific* value has sensible defaults so you don't have to specify it unless you wnat to override it. The [default values from NuGetizer.props](src/NuGetizer.Tasks/NuGetizer.props) are:
When an item specifies *FrameworkSpecific=true*, the project's target framework is added to the final package path, such as `lib\netstandard2.0\My.dll`. Since the package folder itself typically determines whether it contains framework-specific files or not, the *FrameworkSpecific* value has sensible defaults so you don't have to specify it unless you want to override it. The [default values from NuGetizer.props](src/NuGetizer.Tasks/NuGetizer.props) are:

| PackFolder | FrameworkSpecific |
|------------------|-------------------|
Expand Down Expand Up @@ -208,13 +208,13 @@ When copying items to the output directory, you're implicitly saying that those

Given this common scenario, NuGetizer changes the default `PackFolder` metadata for packable items (i.e. those with explicit `Pack=true` metadata or defaulted to *true*, such as `Content` items) to match the `PackFolder` property defined for the project's built output, whenever `CopyToOutputDirectory` is not empty or *Never*.

Like other default inference behaviors, you can always opt out of it by specifying an explicit *PackFolder` item metadata.
Like other default inference behaviors, you can always opt out of it by specifying an explicit `PackFolder` item metadata.

In addition, the resulting `PackageFile` items for these items point to the location in the project's output folder, rather than the source location. This makes it easier to have custom behavior that might modify the item after copying to the output directory.

### PackageReference

Package references are turned into package dependencies by default (essentially converting `<PackageReference>` to `<PackageFile ... PackFolder="Dependency">`), unless `PackDependencies` property is `false`. If the package reference specifies `PrivateAssets="all"`, however, it's not added as a dependency. Instead, in that case, all the contributed files to the compilation are placed in the same `PackFolder` as the project's build output (if packable, depending on `PackBuildOutput` property).
Package references are turned into package dependencies by default (essentially converting `<PackageReference>` to `<PackageFile ... PackFolder="Dependency">`), unless `PackDependencies` property is `false`. If the package reference specifies `PrivateAssets="all"`, however, it's not added as a dependency. Instead, in that case, all the files contributed to the compilation are placed in the same `PackFolder` as the project's build output (if packable, depending on `PackBuildOutput` property).

Build-only dependencies that don't contribute assemblies to the output (i.e. analyzers or things like [GitInfo](https://github.com/kzu/GitInfo) or [ThisAssembly](https://github.com/kzu/ThisAssembly) won't cause any extra items.

Expand Down Expand Up @@ -283,7 +283,7 @@ Finally, you can focedly turn a project reference build output into a private as

## Advanced Features

This section contains miscelaneous useful features that are typically used in advanced scenarios and
This section contains miscellaneous useful features that are typically used in advanced scenarios and
are not necessarily mainstream.

### Dynamically Extending Package Contents
Expand All @@ -305,7 +305,7 @@ place them all under the `docs` folder in the `.nupkg`, preserving their origina
### Packing arbitrary files from referenced packages

If you want to pack files from referenced packages, you can simply add `PackageReference` attribute
to `PackageFile`. Say we want to resuse the awesome icon from the
to `PackageFile`. Say we want to reuse the awesome icon from the
[ThisAssembly](https://nuget.org/packages/ThisAssembly) package, we can just bring it in with:

```xml
Expand Down