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.

[DamianEdwards]

This is an interesting and honestly understandable request. I have similar concerns to @jjonescz about ambiguity when CPM is involved, as we'd need to detect that alter the behavior accordingly, including when running dotnet project convert. Generally speaking, I'm not aware of anywhere else that omitting versions implies use latest staple, but happy to be corrected. While it might be attractive, completely hiding the version specification could be a level of "magic" that results in more "harm" than "good" through lost time to diagnosing issues due to the behavior not being intuited.

Applying similar behavior to #:sdk would be harder as the underlying infrastructure is quite different (SDK resolvers vs. package restore) and it doesn't currently support the wildcard syntax AFAIK (although I'm sure that could be fixed with more work).

@baronfel for his thoughts.

[baronfel]

There are a few CLI gestures where the absence of a version implies "latest stable"

• dotnet package add
• dnx/dotnet tool exec
• dotnet tool install

But nothing around MSBuild SDK management, yeah. I could see it making sense in this context, and I think "latest" is a better default than that alternative for sure.

[DamianEdwards]

Right, I meant to qualify what I said as I'm not aware of other files where omitting the version implies latest, in our stack or others, but I'm likely wrong anyway 😄.

If we assume we can accept the CPM or not thing, then I guess it's fairly straightforward, in that we'd simply infer "no version" as "*" and NuGet would do what it normally does (float to latest). If users want to force a restore to reevaluate the wildcard, I think they can do that using the usual mechanisms (NuGet cache clearing, --no-cache and --no-http-cache options, etc.).

@jjonescz what are your thoughts?

[jjonescz]

we'd simply infer "no version" as "*"

Some packages might not contain a stable version but I guess that's fine? dotnet package add would also fail in that case without --prerelease I believe. So #:package could also fail and require you to specify @*-* explicitly.

what are your thoughts?

I like the current consistency with PackageReference (no need for another decoding ring), but I also acknowledge that file-based apps could be simpler. So detecting whether CPM is enabled and if not going with * seems fine to me.

That's for #:package. If we wanted that for #:sdk as well, I think it would be nice if the underlying infrastructure supported wildcards first. But I guess run-file could do nuget api calls to find the latest version if we really wanted to... (Since it's not possible to do even #:sdk Xyz@* today, it would be a big help to simplicity if run-file could make it work, i.e., allow customers to use SDKs without looking up versions first, even bigger than supporting #:package without versions since customers can at least do @* there today, so improving that is not that much simpler. Also I think SDKs don't participate in CPM, hence supporting #:sdk without versions feels orthogonal in multiple ways.)

[DamianEdwards]

I think making run-file do the work for the SDK directive to support no version for NuGet SDKs is a step too far. I agree it would be a good addition but support for wildcards shoulds be added to the SDK NuGet resolver directly and then we could support no versions the same way as we would for packages.

Given NuGet SDKs are still a minority case, it seems worthwhile adding support for implicit versions for packages in the meantime. Note that this would be in source only, as I don't think there's a gesture to represent this in dotnet package add --file, as omitting the version there should continue to do what it does today (install the latest version and put the version number in source). If we really did want to support referencing packages this way via the CLI, we could consider adding something like dotnet package add <PackageId> --file <AppFile> --implicit-version.