NuGet

[marchenko1985]

Initial proposal to deal with #7 issue

[dmcgiv]

BA Review

1. Requirement Summary

• Problem: make DKIM.Net consumable through NuGet so users can install it without manually referencing source or binaries.
• Capability: add packaging metadata and update project/test configuration toward NuGet package creation.
• Expected outcome: maintainers can produce a usable NuGet package for the library.

2. Requirement Health

• Clarity: Low. The issue asks for NuGet availability, but the PR includes broader test framework and project upgrades without a clear packaging/release requirement.
• Completeness: Low. Package identity, versioning, license, target frameworks, dependency metadata, build process, publishing ownership, and release criteria are incomplete.
• Testability: Low. There is no explicit acceptance path for packing, installing, and consuming the package.
• Dependency Risk: Medium. Packaging depends on legacy .NET Framework tooling, NuGet conventions, and test/build compatibility.
• Conflict Risk: High. The PR changes project/test framework setup and assembly version values, which may conflict with a packaging-only objective.

3. Key Assumptions

Confirmed facts: the related issue requests a NuGet package; the PR adds a .nuspec and changes project files/tests.
Inferred assumptions: the intended package is for the DKIM.Net library rather than the test project; publishing to nuget.org may be desired.
Unknowns: package ID, semantic version, license, supported frameworks, release owner, whether test migration is in scope, and whether existing version numbers should be preserved.

4. Gaps Identified

• Gap: Package metadata is placeholder-based. Why it matters: $id$, $version$, $title$, and $description$ are not an agreed release specification. Required clarification: define final package ID, version, title, description, tags, license, and project/repository URLs.
• Gap: Scope includes non-packaging changes. Why it matters: converting tests and changing project GUID/version values increases regression risk. Required clarification: confirm whether this PR should only add packaging or also modernize tests/projects.
• Gap: Release process is undefined. Why it matters: maintainers need repeatable pack, verify, and publish steps. Required clarification: define who publishes, where, and from which branch/tag.
• Gap: Consumer compatibility is not defined. Why it matters: NuGet users need supported .NET target frameworks and dependencies. Required clarification: define supported target frameworks and package contents.

5. Cross-Requirement Relationships

Related Requirement	Relationship	Finding	Impact	Recommended Action
Issue #7, Can someone Nuget this library?	Direct dependency	PR appears intended to address package distribution.	The requirement is valid, but acceptance needs package usability criteria.	Link this PR explicitly to #7 and define done conditions.
PR changes to tests/project files	Scope conflict	Test framework migration and version changes go beyond packaging.	Increased risk of delaying or breaking a simple package release.	Split packaging from project modernization unless both are intentionally required.
Existing assembly version 1.2.0.0	Potential conflict	PR changes test assembly version to 1.0.0.0 and package version is unspecified.	Versioning may confuse consumers and maintainers.	Confirm versioning strategy before merge.

6. Business Rules Identified

• The package should distribute the DKIM.Net library, not test-only artifacts.
• Package metadata must be explicit before release.
• Requires confirmation: package version should align with assembly/release version.
• Requires confirmation: publishing should occur only after pack/install verification succeeds.

7. Edge Cases and Exceptions

Package includes wrong assemblies, package ID conflicts on NuGet, missing license metadata, unsupported target framework for consumers, packaging accidentally includes tests or secrets, version lower than existing releases, package builds locally but cannot be installed in a clean project.

8. Dependencies

Requirement dependencies: package identity, versioning, license, supported frameworks, release owner.
System dependencies: MSBuild/Visual Studio or NuGet CLI compatible with the legacy project.
Data dependencies: nuspec metadata, assembly version, package contents.
External dependencies: NuGet feed/nuget.org access and ownership.
Delivery dependencies: clean build, pack, local install test, publish credentials.

9. Risks

The PR may solve the distribution request only partially because metadata remains unresolved. The broader project/test changes create unnecessary merge and regression risk if the business goal is simply to publish the library package.

10. Follow-Up Questions

Critical

1. What exact NuGet package ID, version, description, license, and supported target framework should be released?
2. Should this PR be limited to packaging, or should test/project modernization remain in scope?
3. Who owns publishing the package and to which feed?

Important

1. Should the package version align with the current assembly version or start with a new semantic version?
2. What verification is required before publishing, such as pack, local install, sample DKIM signing, or CI build?
3. Should issue Can someone Nuget this library? #7 be closed automatically by this PR once packaging is complete?

Advisory

1. Should package README/release notes include known limitations around attachments and alternate views?

11. Recommended Requirement

Requirement ID: BA-DKIM-NUGET-001
Title: Publish DKIM.Net as a NuGet Package
Business Need: Make DKIM.Net easy for .NET developers to install, version, and reference through standard package management.
Requirement: Provide explicit NuGet packaging for the DKIM.Net library, including agreed metadata, supported framework information, package contents, versioning, and repeatable pack/publish instructions.
Actors: Library maintainer, .NET consumer, NuGet feed.
Preconditions: Package metadata and release version are agreed; project builds successfully.
Trigger: Maintainer prepares a DKIM.Net release.
Main Behaviour: Build library, create NuGet package, verify installation in a clean consumer project, and publish to the agreed feed.
Business Rules: Package must not include test artifacts or secrets; metadata must be explicit; versioning requires stakeholder decision.
Exceptions: Build failure, package ID conflict, missing metadata, failed local install.
Dependencies: NuGet tooling, release ownership, target framework decision.

12. Acceptance Criteria

Given package metadata is agreed, when the maintainer runs the packaging command, then a .nupkg is created with explicit ID, version, title, description, license, authors, tags, and project URL.
Given the package is created, when it is installed into a clean compatible .NET project, then DKIM.Net can be referenced without manual source or binary copying.
Given publishing is approved, when the maintainer publishes the package to the agreed feed, then consumers can install that exact version.
Blocked acceptance criterion: final package identity and version cannot be accepted until release metadata is confirmed.