Our code has a lot of the following:
EndpointConfig.cs:
Configure.Instance.Configurer.ConfigureComponent<Foo>(ComponentCallModelEnum.None);
Configure.Instance.Configurer.ConfigureComponent<Bar>(ComponentCallModelEnum.None);
etc, which gives compiler warnings that the ConfigureComponent method is obsolete.
What is the non-obsolete way of doing this?
Replace ComponentCallModelEnum with the appropriate DependencyLifecycle.X
Related
I have installed package OpenIddict.AspNetCore, OpenIddict.EntityFrameworkCore, OpenIddict.Quartz Version 3.1.1 but I'm missing method AddClaims and SetDestinations.
I found ArgumentNullException:
No overload for method 'AddClaims' takes 2 arguments
Please, help me fixing this. Thanks.
You'll need to install the 4.0.0-preview2 packages. The extension method is part of the OpenIddictExtensions class in OpenIddict.Abstractions namespace. However, pre-release versions are generally not stable and the API might change before the actual 4.0 release.
Namespace and Class
The function
Based on the message, I assume you have code that looks like
something.AddClaims(arg1, arg2);
The compiler is telling you that there is an AddClaims method but it should be called with more than two arguments or with one or none, e.g.
something.AddClaims();
something.AddClaims(arg);
something.AddClaims(arg1, arg2, arg3); // and so on
I have this compiler error related to "in expansion of macro ‘CHKERRQ’" from PETSC whenever I call "CHKERRQ", I am not sure what causes it, could anyone please give any advice?
Thanks for your help in advance,
Feng
I solved the problem in the end. The return type of my function is void. I need to set the return type of my function, which calls lots of PETSC routines, to PetscErrorCode.
I'm sure at some point we've all written some code like this:
For Each datVehicle In datVehicles
If datVehicle.ID = -1 Then
datVehicles.Remove(datVehicle)
End If
Next
Which compiles just fine but throws runtime exception because you can't delete an item in an enumeration. Does ReSharper catch things like this?
Resharper 6.1 on VS 2010 does not catch it out-of-teh-box. Resharper does not think it is quite Skeet-code tho as it suggests converting to linq.
No version of ReSharper catches this problem. To create custom pattern that can warn about this condition is not easy because your iteration code can be pretty complex.
If you want to create a custom pattern I would suggest to create a suggestion (may be a warning). Your pattern would look something like that:
$ICOLLECTION$.Remove($arg$)
Where $ICOLLECTION$ is an expression of type System.Collections.Generic.ICollection and $arg$ is an argument placeholder.
This way you'll always have a suggestion ( or warning).
I know that the question is about ReSharper only but I want to show the workaround to complete my answer. The workaround for this problem is to use RemoveAll. Here's the example in C#:
datVehicles.RemoveAll(x => x.Id == -1);
I don't think it does automatically, but you could easily create a custom pattern to identify this for you. See: https://blog.jetbrains.com/dotnet/2010/08/19/highlighting-custom-patterns-with-resharper/
I wasn't aware this syntax was valid.
+ (void) methodName:(TypeObject *)typeObject1:(TypeObject *)typeObject2;
Which is then called like so:
[object methodName:obj1:obj2];
I find it ugly and disturbing, but it builds.
Can someone point me at a reference which explains why this is valid.
FWIW the codebase (inherited) that this comes from, is rife with sloppy, lazy stuff, dozens of spelling errors and looks like it was formatted by someone with no need to ever read it again. (Thank you again uncrustify.)
This is a well-kown and documented feature (pdf, p. 14)
In principle, a Rectangle class could instead implement a setOrigin::
method with no label for the second parameter, which would be invoked
as follows:
[myRectangle setOrigin:30.0 :50.0]; // This is a bad example of multiple parameters
but apple discourage everbody of using parameter passing without keyword:
Use keywords before all arguments.
- (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag; -> Right.
- (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag; -> Wrong.
Why it was allowed by the creators of objective-C, I dont know. Maybe it has to do with the Smalltalk heritage.
Here is a simple explanation of the problem. Keep in mind this isnt the real problem
Lets say in my language functions cannot return pointers and member vars cannot be references. Bison is complaining (with like 40 reduce/reduce problems) about not deducing if the type in type what is a function or member variable. I know it but its ridiculous to have >40 conflicts from this one line.
Class Name { ...
Type& func() {
Type* Var=0
Type What
How should i deal with this? should i use %glr-parser and set expect/expect-rr to a value? or should i use a Type that has everything and filter what is legal or not in code? It looks like my choices are have more conflicts/ambiguity VS writing more code to deal with it. I am not sure which is worse so i wonder if any of you guys had to deal with this.
You shouldn't try to express type constraints in the grammar. This was proven pretty conclusively by the Algol-68 fiasco documented by Wirth and others.