When using FxCop 1.36 for a WPF application with a single window that has yet to be modified, I get the InterfaceMethodsShouldBeCallableByChildTypes error with the following details:
Target : #System.Windows.Markup.IComponentConnector.Connect(System.Int32,System.Object) (IntrospectionTargetMember)
Resolution : "Make 'MainWindow' sealed (a breaking change if
this class has previously shipped), implement the method
non-explicitly, or implement a new method that exposes
the functionality of 'IComponentConnector.Connect(int,
object)' and is visible to derived classes."
Help : http://msdn2.microsoft.com/library/ms182153(VS.90).aspx (String)
Category : Microsoft.Design (String)
CheckId : CA1033 (String)
RuleFile : Design Rules (String)
Info : "Explicit method implementations are defined with private
accessibility. Classes that derive from classes with
explicit method implementations and choose to re-declare
them on the class will not be able to call into the
base class implementation unless the base class has
provided an alternate method with appropriate accessibility.
When overriding a base class method that has been hidden
by explicit interface implementation, in order to call
into the base class implementation, a derived class
must cast the base pointer to the relevant interface.
When calling through this reference, however, the
derived class implementation will actually be invoked,
resulting in recursion and an eventual stack overflow."
Created : 08/12/2008 22:26:37 (DateTime)
LastSeen : 08/12/2008 22:41:05 (DateTime)
Status : Active (MessageStatus)
Fix Category : NonBreaking (FixCategories)
}
Should this simply be ignored?
Ignore it, this is standard code that is in every WPF application and you don't see people complaining about net being able to call IComponentConnector.Connect from derived classes - so it's probably safe.
In general I think you should handle FxCop output as suggestions that have to be considered carefully, I've got a lot of bad advice from FxCop in the past.
Depends on what you expect an inheriter to do.
If you are not expecting this class to be inherited then it should be sealed and the problem goes away.
If you are expecting it to be inherited then you are taking the ability of the inheriting class to override the interface methods and still call them (i.e. base.methodname()). If that is your intent then you can ignore the warning.
However, that is not expected behaviour for inheritable classes so you should expose the interface publicly (i.e. An implicit interface instead of an explicit interface).
Related
I am using the AutoDataAttribute class within AutoFixture.Xunit2 in a lot of projects. The recommended approach to add your own customizations seems to be a derived attribute like the following (note I am using FakeItEasy):
public class AutoFakeItEasyDataAttribute : AutoDataAttribute
{
public AutoFakeItEasyDataAttribute()
: base(() => new Fixture().Customize(new DomainCustomization()))
{
}
}
In an effort to reduce code copying/pasting, I wanted to abstract this derived attribute to a package we could consume in our projects. However, despite attempts utilizing dependency injection with this library and running into CLR issues with the DataAttribute not able to take anything beyond basic "primitives", I have ran into the proverbial "brick-wall". Obviously constructor injection doesn't seem to work here nor property injection to my knowledge (although unlikely that matters as the property isn't allocated until after the constructor call anyway).
The bottom line, I am looking for a way to include this derived attribute into a package but in a way where the domains can be customized for each individual project's needs?
I don't think what you're trying to achieve is possible due to how attributes work in C#. As you mentioned yourself you cannot pass into the attributes but a small set of primitive values, and in xUnit 2 data attributes don't have access to the test class instance, so you can not inject instances via reflection.
You could theoretically inject the IFixture instance into the test class using the library you mentioned (which I think is a horrible practice, that promotes sloppier tests), but then you'd have to give up the decorator notation of AutoFixture and use the declarative notation, to create your test data.
the full sentence taken from the EJB3.2 specifications:
When interacting with a reference to the no-interface view, the client
must not make any assumptions regarding the internal implementation of
the reference, such as any instance-specific state that may be
present in the reference
I'm actually trying to understand what that actually mean and I was wondering if someone could kindly provide some examples.
EDIT:
The Above sentence is take from Section 3.4.4 Session Bean’s No-Interface View, maybe this info is helpful
When generating a no-interface view proxy, the EJB container must create a subclass of the EJB class and override all public methods to provide proxying behavior (like security, transactions).
You can get a reference to the bean with (eg. for passing it to another ejb):
NoInterfaceBean bean = ejbContext.getBusinessObject(NoInterfaceBean.class);
This returns a reference with a class-type that is the same as the bean class itself (normally if the EJB has a business interface it would return the interface class), but it is not a reference to an instance of NoInterfaceBean (but to that proxy class with the same name). Think of it as a reference to a pimped version of your bean, about which you
must not make any assumptions regarding the internal implementation
It's basically the same with "normal" EJB's. You know that there is some magic around your bean instance, but since you get the interface as class-type it's already clear that every class implementing the interface can have a different internal implementation.
So the specification emphasizes this difference at that point. Even if it looks like a reference to your concrete class it is none (as they say in the next paragraph of the specification JSR-000345 Enterprise JavaBeansTM 3.2 Final Release:
Although the reference object is type-compatible with the
corresponding bean class type, there is no prescribed relationship
between the internal implementation of the reference and the
implementation of the bean instance.
I am writing verification IP for some interface and facing with one interesting item, which I think is somehow basic for OOP.
So in my driver I have functions e.g. configMaster, which is DUT specific. And VIP user may want to override that function. Now I want to provide mechanism for user to do that.
I think the best way of overriding the VIP driver class functions would be following
User extends the driver class
In the extended class user redefines the driver methods that he wants. If there are several methods that user doesn’t want to override that’s fine.
Using factory override method user overrides the driver class with the
extended user_driver class
The thing I don’t like here that user each time running the simulation should specify the factory override command.
Could you please share your opinion is this right way to do? Are there other ways?
Thanks
Hayk
Step 3 is not always mandatory . After overriding the class the user can directly use the derived class in his TB. This will mostly be the case if the TB is being built afresh or the user is integrating this IP as a new component into an existing TB.
In case the VIP was already present in a TB and you are now providing new set of functions to the user to override or the user itself want to use the override mechanism preferring to instantiate the base class provided by the VIP and use the override mechanism later , user can use the set_type_override_by_type function .
The function can be embedded into a base test and all the derived test will implicitly use the use vip class derived by the user without the need to specify it explicitly in the command line for each test case.
There are 4 flavor to the type override function .
http://www.testbench.in/UT_06_UVM_FACTORY.html
The function can also be used in a base env too , the user has to ensure that the type override function is called before the class is create for the override mechanism to take effect.
As I understand Caliburn.Micro does a considerable amount of auto-wiring and plumbing for a WPF project in a convention-based manner; employing MVVM.
Question: Are there any C# specific parts in Caliburn.Micro; which used some C#-only features? What parts of Caliburn.Micro can not be used with F# code? What do I lose by using F#?
Unfortunately, Caliburn.Micro and F# don't work that well together.
For example, Caliburn.Micro treats views as regular classes during convention matching (via reflection), which is true for C# - views are partial classes.
F# has no support for partial classes and views are XAML files only. That means they can't be resolved by Caliburn.Micro. It also means you will have problem wiring up IoC container in the bootstrapper, because it won't be able to create views - at least not without manual registration with Application.LoadComponent and such.
Setting up the boostrapper was also a pain, because you have to specify the key in App.xaml, but for whatever reason that key was not matched with the class. Bootstrapper<T> also passes bool useApplication = true to BootstrapperBase as a default - and F# had different problems depending whether that flag was set or not, unfortunately I don't remember the details. That's because in F# you wire up the entry point to the application yourself, while Caliburn.Micro is built to intercept that step automatically. That causes conflicts...
If you get it to work by overriding convention resolution mechanism completely and by bending any IoC container to your will, more power to you. In my opinion, currently there's just too much friction.
Personally, I'd set up the core foundation for the application in C# using Caliburn.Micro and do the 'real work' in F#. Alternatively, I think you can even have view models written in F# in separate project, views in C# project, then you'd just have to adjust how the convention lookup works in the bootstrapper. I'm not exactly sure about that approach though so your mileage may vary and proceed with caution.
That's a nice question. If you go through with it, be sure to let us know how it goes. I was looking at Caliburn for a side project, but I didn't make much progress on it.
So to kick off, something you might have already stumbled upon:
Lambda expression overload of NotifyOfPropertyChange
The basic method for raising PropertyChanged events has two overrides. One that takes property name as a string, and another that takes a lambda expression. The latter uses a clever trick/ugly hack for extracting a property name from the expression's body. This gives you a nice, succinct syntax in C# that's to some extent checked by the compiler:
public string SomeProp
{
get { return someField; }
set
{
someField = value;
NotifyOfPropertyChange(() => SomeProp);
}
}
But this doesn't translate well to F#. Your choices are either to fallback to the string one, or sugar it by using quotations. I've used something like this:
let notify<'a> (notifier: PropertyChangedBase) (expr: Expr<'a>) =
let name =
match expr with
| PropertyGet (_, pi, _) -> pi.Name
| _ -> failwith "Can't get property name to notify"
notifier.NotifyOfPropertyChange(name)
Which was called like this:
member this.SomeProp
with get () =
someField
and set(value) =
someField <- value
notify this <# this.SomeProp #>
I believe you could take it a step further and roll it into your own PropertyChanged class built on top of PropertyChangedBase.
I've been trying to find some info on difference between instantiating form fields through static method and the new keyword. Can somebody tell me what are the practical implications, limitations, between new MyFormField and MyFormField::create() esp. with regards to SilverStripe
Using the create factory method would check for overloads (set via Object::useCustomClass()) and return an instance of the custom class in that case.
This method first for strong class overloads (singletons & DB
interaction), then custom class overloads. If an overload is found, an
instance of this is returned rather than the original class. To
overload a class, use Object::useCustomClass()
So using the create method rather than instantiating the Object yourself would provide a possibility to overload the used Class without altering the code.
see
http://api.silverstripe.org/3.1/class-Object.html#_useCustomClass
http://api.silverstripe.org/3.1/class-Object.html#_create