In a specific project at my work, I have a method that returns IList. But this interface does not contain where, or FindAll filters. However, when I open a new project, IList contains all. What is the difference?
Did you import System.Linq ?
Nope. IEnumerable<T> has "where" as an extension method.
Assuming your project is .Net 3.5 or greater, you need to have using System.Linq;
You might find this useful: LINQ, Where() vs FindAll()
Check .NET Framework of opened framework, may be its .NET Fx 2.
System.Linq added in 3.5
Here's a basic discussion of extension methods in general. As mentioned by others, the Where method is an extension method found in the System.Linq namespace so you need to import it in order to have intellisense detect the existence of those methods.
Related
It seems like there are methods and properties of ObservableCollection that are missing. I'm so confused.
Here is a screenshot of an old project:
And now my current project:
This is the using statement in both projects:
using System.Collections.ObjectModel;
Did they update the SDK and removed all of the methods or am I using the wrong ObservableCollection? I have no idea what's going on.
When you see the down arrow on a method that means that method is not part of the class but is a "Extension Method". Extension methods are basically static methods from other classes that act like instance methods on the class you are working with.
Most of the items in your list are from adding using System.Linq; to the top of your file. This causes all of the extension methods in System.Linq.Enumerable to show up in the list, this will give you things like All<> or Any<>. However AddRange<> is not a standard extension method in System.Linq and may be added by some other 3rd party library (or some namespace in .NET I am not aware of) that you are using.
The easiest way to find out where you are getting AddRange<> from is go to the project that it works for and then right click on the method in code and you should see a "Go To Definition" or similar1, that should take you to the file or the metadata view of the file that declared that extension method.
1: I use Resharper and it changes my right click menu so I don't know the exact wording
I think you're missing the LINQ extensions. Try adding:
using System.Linq;
The "missing" methods are LINQ extension methods. Add LINQ to your list of included libraries.
I'm trying to update a project which makes heavy use of comparison against SyntaxToken.Kind. This property appears to have disappeared in newer versions of Roslyn and I wondered if there an alternative method or an extension method I could write to get the same functionality?
The code has many references such as:
if (expression.OperatorToken.Kind == SyntaxKind.PlusEqualsToken)
Any ideas?
Add a using for Microsoft.CodeAnalysis.CSharp.Syntax, and then use the CSharpKind() extension method.
Using ReSharper, I occasionally get quick-fix suggestions for importing a namespace for a LINQ operation. So given the following code in a brand-new class:
linqToSqlDataContext.Customers.Count();
I get a quick-fix drop down as follows:
Which should I choose, and what is the difference between them?
System.Linq.Dynamic is the namespace for Dynamic LINQ. You shouldn't be seeing that as an option unless you've added a reference to the Dynamic LINQ assembly though. Have you done so?
You should only do that if you actually want to use Dynamic LINQ.
Dynamic LINQ lets you express queries as text - a bit like with DataTable.Select. I've personally never found a use for it, but you may want it. It should be a deliberate choice though. Most of the time you'll be fine with the statically typed LINQ to Objects.
EDIT: As per the OP's comment, the code for Dynamic LINQ could have been added directly to the project, rather than referenced as a separate assembly. Even if you do actually want to use Dynamic LINQ, I'd strongly recommend keeping it in a separate assembly rather than mixing it in with your own code.
Dynamic LINQ is a non-typesafe version of LINQ. That takes strings rather than lambdas to generate the queries.
Unless you need any of the specialist functionality that this will give you use the Enumerable version instead.
Scott Hanselman did a good explanation of DynamicQueryable. Basically it allows you to have a little more dynamism where the parameters may change during runtime.
Argh! The answer in the end was that one of my colleagues added the DynamicQueryable extensions class to our project (from http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx), and ReSharper was picking that up.
Since I don't see any example of usage of Dynamic LINQ here, here it goes:
In my faculty project I had a situation where I would use Repository pattern to make an abstraction over my used database technology, particulary Entity Framework.
In my Repository I would have a method something like this:
public IEnumerable<T> Find(Expression<Func<T, bool>> predicate);
As you can see, an Expression is used as the predicate.
Also, I had client-server communication over WCF. Since Expressions are not Serializable, I had to use Dynamic LINQ where I would just send string representation of predicates and use them with my Repository.
I was having troubles earlier while trying to declare a ChangeAction parameter in a method, with the IDE saying I might be missing a Namespace.
So I right click it and Resolve it and find that System.Data.Linq has been added and now everything is fine.
What is the difference between these two namespaces?
As I understand it, System.Linq is about the overall Linq library -- it applies to all data types like Lists and such.
System.Data.Linq is about databases (aka Linq to SQL), which includes tracking changes (ChangeAction).
I believe System.Linq is LINQ-OBJECTS specific (IEnumerable, IQueryable, etc)
Whilst System.Data.Linq is LINQ-SQL specific (DataContext, etc)
As described here:
http://msdn.microsoft.com/en-us/library/system.data.linq.aspx
System.Data.Linq is for accessing relational data
To my understanding, System.Linq is generic-level implementation which relies on
IEnumerable whereas System.Data.Linq is provider-specific (LINQ to SQL) which relies on IQueryable.
Is there a way to use reflection to completely "scan" an assembly to see if System.IO.File or System.IO.Directory is ever used? These are just example classes. Just wondering if there is a way to do it via reflection (vs code analysis).
update:
see comments
As Tommy Carlier suggested, it's very easy to do with Cecil.
using Mono.Cecil;
// ..
var assembly = AssemblyFactory.GetAssembly ("Foo.Bar.dll");
var module = assembly.MainModule;
bool references_file = module.TypeReferences.Contains ("System.IO.File");
The fantastic NDepend tool will give you this sort of dependency information.
Load your dll in NDepend and either use the GUI to find what you want, or the following CQL query:
SELECT TYPES WHERE IsDirectlyUsing "System.IO.File"
and you should get a list of all the types that use this.
I'd suggest looking at Mono Cecil for this. With Cecil, you can enumerate all the classes, methods and even the IL-instructions (including all the methods calls).
I don't remember where, but I found this handy piece of code:
http://gist.github.com/raw/104001/5ed01ea8a3bf7c8ad669d836de48209048d02b96/MethodBaseRocks.cs
It adds an extension method to MethodInfo/ConstructorInfo that parses the ILByteArray into Instruction objects.
So with this, you could loop over every MethodInfo/ConstructorInfo in the assembly, then loop over every Instruction on that MethodInfo/ConstructorInfo, and check if any of those Instruction objects contains an Operand which is an instance of a MemberInfo which has a DeclaringType that is equal to either class.
You can get a list of dependent assemblies via Assembly.GetExecutingAssembly().GetReferencedAssemblies(). I don't believe you can comprehend namespace usage via reflection. Try looking at System.CodeDom. That may help you parse the code.
.NET Reflector can do this, or something close to it. The other day I checked to see where a particular type was used.
ReSharper might also help. I do this with my own symbols all the time - I suppose it would also work for .NET Framework types.