I am learning the Prism framework and how MEF is integrated with it... I am looking at the "StockTraderRI" demo solution that comes with Prism as an example...
When the [EXPORT] attribute is used on a viewmodel such as this: [Export(typeof(TrendLineViewModel))]
Does MEF create a list of these in one of its internal structures so that when it is imported like this:
[Import]
TrendLineViewModel ViewModel
it can be located?
The it looks like the exporting of views is doing something similar:
[ViewExport(RegionName = RegionNames.ResearchRegion)]
which is then used in the AutoPopulateExportedViewsBehavior method to inject the views in the regions.. is this correct?
Thanks
Harold
When you put "attributes" (the square bracket things) on types, you are attaching "metadata" to that type that can be discovered at runtime by using reflection.
When you configure MEF you give it a Catalog which tells it which assemblies it should scan for the [Import] and [Export] metadata attributes. For example a DirectoryCatalog will get MEF to scan a set of assemblies/DLLs in a particular directory.
When you ask for a type to be created/composed, it knows how to resolve the creation of that part i.e. it matches up [Import] and [Export]s which are of the same contract.
http://msdn.microsoft.com/en-us/library/dd460648.aspx
http://mef.codeplex.com/wikipage?title=Using%20Catalogs
http://mef.codeplex.com/wikipage?title=Overview
Related
I'm attempting to create a T4 template that generates source code for calling stored procedures that are contained in another project in my solution. I am able to successfully enumerate the .sql files in the solution, add them to a TSqlModel, and use that model to retrieve the list of stored procedures as TSqlObject instances. Now, I need to enumerate the parameters for each stored procedure, and this is where I'm getting hung up.
When I debug my template, I can see that the TSqlObject instances have a ContextObject property, and this property contains, among other things, the list of parameters that I need to generate my code. When I attempt to access this property from my template, however, the compiler complains that the property doesn't exist:
Error 1 Compiling transformation: 'Microsoft.SqlServer.Dac.Model.TSqlObject' does not contain a definition for 'ContextObject' and no extension method 'ContextObject' accepting a first argument of type 'Microsoft.SqlServer.Dac.Model.TSqlObject' could be found (are you missing a using directive or an assembly reference?) d:\Code\cs\test_sproccodegen\CallingProject\sproc_template.tt 34 111 CallingProject
I can definitely access this ContextObject property from the Immediate window while debugging, but it is not available at compile time.
What am I doing wrong?
The property isn't listed in the API, which probably means it's internal or private. Only public and protected accessible members are included in the docs.
Checking it out in JustDecompile, you can see it is, in fact, internal.
That's an internal method as mentioned by Will in the question comments. You should use the public APIs instead. The following documenation should help you get started:
Model API Reference
Public Model Tutorial
Dac samples project. There aren't any T4 template examples but it has a lot of examples of querying and even manipulating the model. You just need to put that in T4 template form.
I am having a problem with a circular dependency. Similar question have been asked and I have read a lot of answers. Most deal with a work-around but I would like to refactor so what I have it correct and I would like some input on where I have gone wrong. I can change what I am doing but not the entire project architecture.
I am using VB.Net in Visual Studio 2012.
I have two class libraries:
DataLayer for accessing the database.
DataObject which contains classes that represents my business objects.
My Presentation Layer calls methods in the DataLayer which returns objects from the DataObject class library.
(I have simplified somewhat – I actually have a controller layer but it needs references to the two class libraries above. This is an existing architecture that is from before my time.)
In the DataObject class library I have an abstract class that represents a file. It has properties such as filename, userID, etc. It also has a method, GetFile(), that I code in the derived classes because there are different ways of getting the file. A DataLayer method returns a collection of these file objects, but I don't want to get the actual file until it's needed.
So far, I have a derived class that calls a webService (using properties from the baseClass) and a derived class that accesses the fileSystem. Both return a byte array representing the file. The calling class does not need to know how the file is retrieved.
Now I have a new requirement to build the file on the fly using data from the database. I can get all the data I need using the properties in the base class.
My issue is that my GetFile() method will need to access my DataLayer class library to pull data from the database which causes a circular dependency. The DataLayer class library has a reference to DataObject since that is what it returns. But now I need to call the DataLayer from a class in DataObjects.
I could call the DataLayer from presentation and pass the result to
my DataObject’s GetFile() method, but then my presentation layer
needs to do something special for this derived class. My goal is
that the derived class handles GetFile without presentation knowing
about the implementation.
I could create a new class library for this DataLayer code but I
don't like a special case.
I could access the DB directly in the DataObject class but that
circumvents the layered architecture.
I can’t change our architecture, but I can change my approach.
Any opinions?
I think I have the answer.
In my concrete class, when I am loading the data initially (in the DataLayer), I will get all the data I need to create the file. I'll store it in a new property in my concrete class which my GetFile() method will use to build the file.
This has a little more overhead - I make DB calls and put all this data in memory when it may not be needed. I'll give it a try and see how performance is.
Any critiques of this approach?
I am trying to create a Visual Studio extension which handles a multi-language content type. Much like some mvc-templates and Django or ASP.NET which a certain part of the code is in another language.
I know that I should use Projection and I already checked Django for Visual Studio extension but the solution there includes creating a Language Service and going to the trouble of creating all bits and pieces related to a code editor. Here I am trying to achieve the same goal just by using MEF.
I know that you can use IProjectionBuffer CreateProjectionBuffer() to create a projection but the question is how to replace the current TextBuffer with the created one and when is the best time to do it.
Also one may expect that if he specifies a base definition of type "projection" like this:
[Export]
[Name("Whatever")]
[BaseDefinition("code")]
[BaseDefinition("projection")]
internal static ContentTypeDefinition WhateverContentType = null;
the received TextBuffer in providers to be of type IProjectionBuffer (after all IProjectionBuffer is inherited from ITextBuffer). Which are not and it seems that a projection base definition has no effect what so ever.
So if I want to rephrase my question in a tldr version:
How and when do you apply an IProjectionBuffer to current view (using MEF and without creating an editor instance)?
So if I understand your question correctly, the answer is "you don't." A IWpfTextView is bound to a implementation of ITextBuffer (or a derived type, like IProjectionBuffer) at creation time, and can't be changed. Even if you could, many other extensions and language services would be most surprised by this and would probably crash.
To address your second question about content types: simply declaring you have a base content type of "projection" doesn't make you a projection buffer. All that really states is you might be creating projection buffers of that type, and when you do you want some extra ITagger support so taggers project through to the source buffers as you might expect them to.
I'm working on a large Asp.Net MVC3 application (>50 views) and we are currently planning on using Unity for our dependency injection framework. For ease of maintenance, I would like to be able to query the assembly to find all of the base types, then register them with Unity.
Based on sample code from the Unity MVC3 Project for registering all controllers, I tried the following code -
var orchestratorTypes = (from t in Assembly.GetCallingAssembly().GetTypes()
where typeof(IOrchesratorBase).IsAssignableFrom(t) &&
!t.IsAbstract
select t).ToList();
orchestratorTypes.ForEach(t => container.RegisterType(t);
When I run the application I get the following error message
The current type, WwpMvcHelpers.BaseClasses.IOrchesratorBase, is an interface and cannot be constructed. Are you missing a type mapping?
If I register the class using individually, as below -
container.RegisterType<IOrchesratorBase, HomeOrchestrator>();
Everything works correctly. Is there a way to do this so that I don't have to register each type individually?
EDIT
Per request, my inheritance hierarchy is
HomeOrcestrator <- IOrchesratorBaseList<LocalModel>
<- OrchesratorBase<LocalModel> <- IOrchesratorBase
The usage in the controller is
public class HomeController : ControllerListBase <HomeOrchestrator, LocalModel>
{
public HomeController() {}
public HomeController(IOrchesratorBase homeOrchestrator) {
this.Orchestrator = (HomeOrchestrator) homeOrchestrator;
}
The LINQ to get the types appears to work. I don't think that's your problem.
You'll get a similar error if you just write
container.RegisterType(typeof(HomeOrchestrator));
and call container.Resolve<IOrchesratorBase>().
In other words, RegisterType(t) is not the same as RegisterType<I, T>().
The real question is, what are you resolving and how do you want it resolved? Your query is finding implementors of IOrchesratorBase. Are your injection constructor parameters of that type? If so, what's Unity supposed to do when 20 types implement that interface?
Can you provide more information on your class/interface hierarchy, constructor parameters, and what you expect/want to happen?
(I'd refactor to change IOrchesratorBase to IOrchestratorBase, BTW.) :)
Edit
Based on the edited question, the problem is that, in order to resolve a HomeController, Unity is looking for a type registration for IOrchesratorBase. It determines the interface type by the parameter types of the constructor with the most parameters.
If you write container.RegisterType<IOrchesratorBase, HomeOrchestrator>() the answer is obvious - Unity will construct an instance of HomeOrchestrator and inject it.
Now, is there more than one type that implements IOrchesratorBase? If so, and you register both of them (explicitly), Unity will use whichever one you register last. That may not be what you want.
If you have multiple controllers, each taking a different interface type in their constructors (with only one implementation per interface), you'll need to figure out what each interface type is and re-run your LINQ registration for each one. That could be done via reflection - find the orchestrators or the controllers.
If you have multiple controllers, each taking the same interface type in their constructors and you want different implementations for each, you've got a problem. You'd have to register named types and determine the names somehow, or something similar.
Unity isn't magic. It can't figure out your intentions.
Addendum
Unity can operate in a convention-over-configuration mode; see Using Unity With Minimal Configuration.
currently I trying to do something a bit tricky which I don't really know if it's possible to do.
I have a class project and I want to divide it in two sections, "Core" and "Client specific developments". And my client wants the source code of this project but I don't want to deliver the source code of the "Core" section, I just want to give him the source of "Client specific developments".
So to demonstrate a practical case let's imagine that I have a partial class named "User" that have two methods "CreateUser" and "CreateUserForClientSite". So "CreateUser" method will be located in "Core" section and "CreateUserForClientSite" will extend "CreateUser" with specific requirements for my client site (remember this methods may NOT be static, so C# 3.0 class extend feature is pointless in this case). If I have the "Core" section in dll can I extend a partial class present in the dll?
Now let's imagine another scenario. What if "Core" have methods that depend on "Client specific developments" classes, and the other way around? Since I can't do circular reference between projects, how can I manage that (is possible)
Thanks
Regarding the partial classes - you must have all the parts of the partial class available at compile time. You just split definition of a class in several files, but it is still a type that belongs to one assembly.
Thus you cannot compile dll with one part and then reference that assembly in another project and add more methods to the partial class.
I suggest to replace partial classes with inheritance in your case, if possible.
More on partial classes in msdn (look at "Restrictions" section).
Regarding the circular references - you'll have to redesign your object model if splitting into two assemblies leads to this problem. Usually, this indicates flaws in the model that should be fixed anyway.
You can define interfaces in the core assembly to break the circular reference. And implement the interfaces in client specific assembly. Take a look at this article for example - How to get rid of circular references in C#