Namespace: CleanCode.GeneralComponents.ControlsAssembly: CleanCode.GeneralComponents (in CleanCode.GeneralComponents.dll) Version: 1.2.3.0 (1.2.03)
public delegate bool RestrictionLambdaDelegate(
string fileName
)
public delegate bool RestrictionLambdaDelegate(
string fileName
)
Public Delegate Function RestrictionLambdaDelegate ( _
fileName As String _
) As Boolean
Public Delegate Function RestrictionLambdaDelegate ( _
fileName As String _
) As Boolean
public delegate bool RestrictionLambdaDelegate(
String^ fileName
)
public delegate bool RestrictionLambdaDelegate(
String^ fileName
)
The
RestrictionLambda is defined as:
public RestrictionLambdaDelegate RestrictionLambda { get; set; }public RestrictionLambdaDelegate RestrictionLambda { get; set; }public <!--Func<string, bool>--> RestrictionLambda { get; set; }public <!--Func<string, bool>--> RestrictionLambda { get; set; }
...rather than just:
...to allow the use of LINQBridge in this library to be transparent to any applications that use it.
That is, by making this library run in .NET 2.0, LINQBridge supplies the necessary constructs
needed to support LINQ. But then the use of
Func(T, TResult) in the library
actually points to
System.Func`1, LINQBridge, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a5da5e61dd87a23.
In a .NET 3.5 application, the same use would point to
System.Func`1, System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089,
hence there would be a compiler error in the parent application, which may be resolved
by adding an explicit reference to LINQBridge, but that is something that the user should not need to do!
Simply changing the property to use an explicit delegate rather than the implicit one removes the ambiguity;
no change is needed in the parent application.
See also: .
System String