This library is used outside of VS, for example in the Git Extensions project (which also uses JTF and vs-mef).

Currently a violation of e.g. Assumes.NotNull produces an exception with message:

An internal error occurred. Please contact Microsoft Support.

Microsoft does not provide support for Git Extensions :)

What's more, the InternalErrorException exception type is private so the library cannot easily trap these and switch them.

https://dotnetfiddle.net/rB8FPD

In the following code, the Requires.NotNull call displays a warning

The Requires.NotNull function should accept values of type T? instead of T

#nullable enable

using System;
using Microsoft;
					
public class Program
{
	public static void Main()
	{
		Console.WriteLine("Hello World");
		
		Foo? str = null;

		Requires.NotNull(str, "");
	}
	
	private class Foo {
	}
}

When the caret is positioned on a parameter declaration for a reference type, we should offer a code fix to add:

Requires.NotNull(p1, nameof(p1));

Similarly, when positioned on an integer/float parameter declaration, we can offer a code fix to add:

Requires.Range(p1 >= 0, nameof(p1));

The single-iteration foreach loops in Requires.NotNullOrEmpty(IEnumerable values, string? parameterName) and Requires.NotNullOrEmpty<T>(IEnumerable<T> values, string? parameterName) can be replaced by a direct call to GetEnumerator().MoveNext(). This results in a slight performance boost and fewer IL instructions generated.

The actual code is below, which could be used as follows.

            throw new ArgumentException("Overlapping spans").AddData(bufferSpans.Key, bufferSpans.Value[s], bufferSpans.Value[s - 1]);
// or
            throw new ArgumentException("Overlapping spans").Modify((e) => e.Data.Add("bufferSpans", bufferSpans));

    public static class ExceptionsWithData
    {
        /// <summary>
        /// Add <paramref name="data"/> to the Data member of <paramref name="e"/> before returning the modified exception.
        /// </summary>
        /// <remarks>
        /// <para>This method should be used to add context (beyond the message and callstack we normally get) to the exception
        /// that would be useful when debugging Watson crashes.</para>
        /// <para>Do not use this method when you expect the exception to be handled.</para>
        /// </remarks>
        public static T AddData<T>(this T e, params object[] data) where T : Exception
        {
            if (data.Length > 0)
            {
                e.Data.Add("AddData", data);
            }
 
            return e;
        }
 
        /// <summary>
        /// Modify <paramref name="e"/> by performing <paramref name="action"/> on it before returning the modified exception.
        /// </summary>
        /// <remarks>
        /// <para>This method should be used to add context (beyond the message and callstack we normally get) to the exception
        /// that would be useful when debugging Watson crashes.</para>
        /// <para>Do not use this method when you expect the exception to be handled.</para>
        /// </remarks>
        public static T Modify<T>(this T e, Action<T> action) where T : Exception
        {
            if (action != null)
            {
                action(e);
            }
 
            return e;
        }
    }

I'm looking at a CPS trace where Requires.NotNullOrEmpty is allocating a fair number of enumerators. The type is statically known to implement IReadOnlyCollection<T>, so an overload that accepted that type could make the cheaper call to Count.

Unfortunately it's unclear which interfaces to support. With overloads for both ICollection<T> and IReadOnlyCollection<T>, calling Requires.NotNullOrEmpty(new List<int>(), "") would not compile due to ambiguity, which isn't a great experience. Is there a clean way to get this benefit for common types without runtime type checks?

I can rewrite the code to avoid the allocations, but it'd be better if this applied across the board for free by simply compiling against a newer version of the library.

Methods on Requires (and possibly other classes such as Assumes etc.) may benefit from CallerArgumentExpressionAttribute.

https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-10#callerargumentexpression-attribute-diagnostics

// before
Requires.NotNull(name, nameof(name));

// after
Requires.NotNull(name);

Hi,

We use ClearlyDefined for information about licenses used in software that we reference. Following text in the NOTICE file is causing ClearlyDefine to recognize the package as containing source code licensed under LGPL-2:

Notwithstanding any other terms, you may reverse engineer this software to the extent
required to debug changes to any libraries licensed under the GNU Lesser General Public License.

Can you change the wording to eliminate references to GNU LGPL?

Thanks!

This issue tracks the adoption blocker issues to switching to the .NET Core project system in VS2017:

Functional issues

• dotnet/Nerdbank.GitVersioning#93 Nerdbank.GitVersioning interop with .NET SDK
• dotnet/sdk#703 DocumentationFile cannot be set in project file
• dotnet/sdk#651 AssemblyInfo.cs should not be generated on package restore
• XLF -> resx generation support (ideally via full Multilingual App Toolkit support)
• ReadOnlySourceTree package support in and for .NET SDK
• MicroBuild signing plugin support in and for .NET SDK
• Get unit tests running at least on net45 if not also netcoreapp1.0
• Verify that pdbgit works properly
• novotnyllc/MSBuildSdkExtras#6 Get nupkg lib folders right.
• Must be able to run Microsoft ship requirement set of FxCop rules (FxCop port)
• Totally portable toolset so it can run without VS2017 installation, or VS2017 installed on MicroBuild agents

Reliability issues

• dotnet/roslyn#16410 VS crashes on open of .NET Core projects far too frequently
• dotnet/roslyn#16673 VS crashes when SolutionCreator.UpdateDocumentAsync gets NullReferenceException back over jsonrpc
• NuGet/Home#4289 PackTask frequently fails with file access conflict

Non-blocking (because some workaround exists) but tracking

• dotnet/project-system#88 Analyzers aren't listed for customization in Solution Explorer
• NuGet/Home#4125 PackageReference should support DevelopmentDependency metadata
• NuGet/Home#4649 PackTask throws NRE when NuspecProperties are specified.
• NuGet/Home#4698 NuGet pack should include satellite assemblies
• https://github.com/dotnet/corefx/issues/16596 TraceListeners don't allow our unit tests to verify calls.

I'm currently trying to update dependencies in my solution to versions corresponding to the new VS version, but I'm running into a problem: the NuGet Package Microsoft.VisualStudio.LanguageServices in version 4.5.0-2.final references Mcirosoft.VisualStudio.Validation in version >= 17.0.71 but the only available non-prerelease version of it on NuGet is 17.0.65.

Could you please release a more recent non-prerelease version of this package on NuGet? Thanks in advance!

I just saw this dotnet/standard#1359 .
I'm not sure if this lib should do similar things.

The type constraint was removed in .NET 4.0. Our own helper extension method should follow suit.

Now, Assumes.NotNull only supports reference type as a parameter.

It would be nice to have a convenience method on Requires which easily allows validating a collection against a predicate. This method could look similar to:

[DebuggerStepThrough]
public static void ValidElements<T>([ValidatedNotNull] IEnumerable<T>? values, Predicate<T> predicate, string parameterName, string message)
{
    if (predicate is null)
    {
        throw new ArgumentNullException(nameof(predicate));
    }

    if (values is object)
    {
        foreach (T value in values)
        {
            if (!predicate(value))
            {
                throw new ArgumentException(message, parameterName);
            }
        }
    }
}

This could then be used like

public void SetFieldWidths(params int[] fieldWidths)
{
    Requires.NotNullOrEmpty(fieldWidths, nameof(fieldWidths));
    Requires.ValidElements(fieldWidths.SkipLast(1), fw => fw >= 0, "All width's except the last must be greater than 0", nameof(fieldWidths));
}

Similarly, adding a Requires.NotDefault<T> for enums.

The description of Requires.NotNullOrEmpty mentions the following:

Throws an exception if the specified parameter is null, has no elements or has an element with a null value.

It confused me for a second that caused me to check the source code to see what it's actually doing.
This method does not check if there's an element that's null. There's Requires.NotNullEmptyOrNullElements for that. This is what I expected, but the summary is incorrect in this case.