Support latest package version by default when no version is specified in `#:package` directive

[jomaxso]

Is your feature request related to a problem? Please describe.

Currently, when adding a NuGet package via the #:package directive in a file-based run, the version must be explicitly specified. For example:

#:package Humanizer@2.*

or

#:package Humanizer@*

These work fine, but if the version is omitted like this:

#:package Humanizer

…it results in an error. This makes the initial user experience more complex, especially for beginners who are unfamiliar with versioning or just want to try out a package quickly.

Describe the solution you'd like

It would be great if omitting the version in the #:package directive would default to the latest stable version available on NuGet. For example:

#:package Humanizer

should internally resolve and use the latest version of the Humanizer package, just as if @* had been specified.

This change would:

• Make scripts easier to write and read.
• Lower the barrier to entry for newcomers.
• Align with common expectations from other package managers and tools.

Additional context

This feature would provide a smoother onboarding experience and allow for quicker experimentation. Explicit versioning can still be used when needed, but shouldn't be required by default for simple scenarios.

[jjonescz]

Note that omitted version already works with Central Package Management (just like in the equivalent <PackageReference>), so this might be a bit ambiguous (does #:package without a version mean 'latest' or that the version is centrally defined?).

Similarly, it'd be inconsistent with <PackageReference> but given the motivation of file-based apps is to lower the entry barrier, that might be acceptable.

[jomaxso]

You're absolutely right that there's a potential ambiguity with Central Package Management (CPM) when no version is specified. However, I believe there's a case to be made for supporting a "latest" fallback behavior, especially for file-based scenarios.

A few points to support this:

• The dotnet add package Humanizer CLI command also does not require a version and implicitly installs the latest stable version. This sets an expectation that "no version = latest" is valid and intuitive.
• File-based scripting often aims for minimal friction and a fast feedback loop, particularly useful for demos, learning, and prototyping.

Perhaps one way to mitigate that could be:

• If the version is centrally defined, use that.
• If not centrally defined, fall back to latest stable.

This would preserve existing CPM behavior while still improving the experience for beginners who aren’t using CPM yet.

Alternatively, a warning could be shown when no version is specified and CPM is detected – just to make the behavior explicit.

In any case, I agree that consistency with <PackageReference> is important, but since #:package is scoped for simplicity and quick prototyping, relaxing the rule could make sense in that context.

[jomaxso]

I think the same default version logic should also apply to the #:sdk directive. It would have the same benefits as with #:package—more consistency and a better developer experience.