|
Edit: Thanks to Eddy Vluggen, and Freak30, problem resolved. The solution was that I needed to create a separate .dll containing only the Interface, and then have both the host application, and the dynamically loaded UserControl, reference the Interface .dll. I define a Control Library in WinForms: it implements two Types: a UserControl, and an Interface, Iinterface. The UserControl, of course, implements the Interface.
Using the standard methods:
1. Assembly LoadedAssembly = Assembly.LoadFile(... filePath to usercontrol .dll ...);
2a. Type LoadedIInterfaceType = LoadedAssembly.GetTypes()[0]; // get the Type of the Interface
2b. Type LoadedUCType = LoadedAssembly.GetTypes()[1]; // get the Type of the UserControl
3. UserControl loadedUC = (UserControl)Activator.CreateInstance(LoadedUCType); This does load, and instantiate, the UserControl at run-time. Of course, because I've cast the loaded UserControl to the "vanilla" UserControl base-Type, any public Fields/Properties/Methods I've deliberately exposed in the UserControl definition are not available.
If I have the loading Application define the same Interface:
interface Iinterface
{
string ID { set; get; }
} Casting the UserControl instnace that shared that interface ... or any interface ... in the loading App would be pointless since that would just produce 'null.
Is there any way I can use the loaded interface Type from step 2a. above to cast the loaded UserControl to the Interface and thus expose its public Fields/Properties/Methods, etc. ?
I am aware I can use reflection to access the internal Fields/Methods that are prescribed by the interface, but I'd much rather ... if it's possible ... get everything in the UserControl that is prescribed in the Interface ... out there.
I can confirm I have a valid reference to the interface in step 2.a above by inserting this code and setting a break-point; all the expected elements are exposed:
var methods = LoadedIInterfaceType .GetMethods();
var types = LoadedIInterfaceType .GetProperties();
var fields = LoadedIInterfaceType .GetFields(); To use that old cliche: "what am I missing, here?"
thanks, Bill
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
modified 30-Jan-15 11:02am.
|
|
|
|
|
A placeholder to program against in the main application.
Move the interface to another assembly and reference that from the main application; next you load usercontrols that implement the interface - but you'd loose the ability to update the interface without updating the main executable. You might also want a factory somewhere that determines what class to instantiate if you pass it an interface.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks, Eddy; I will experiment with creating a .dll containing only the Interface, although it seems weird to have to do that
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
BillWoodruff wrote: although it seems weird to have to do that It sounds weird to not do that, from my point of view.
What would you use as a base-class to reference the control in the application? Both UserControl and Object will not know any specifics - you'd have to use reflection to invoke anything, which defeats the reasoning on using an interface.
It sounds like you want to have a "general" way of talking to dynamic loaded UserControls.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: It sounds like you want to have a "general" way of talking to dynamic loaded UserControls. I would have guessed ... before today ... that given a valid reference to a Type (an Interface) one could somehow cast another valid reference (to an instantiated object that implements the Interface) to the Interface.
But, looks like this is not possible.
Thanks again, for your reply.
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
One can; if your IUserControl is in assembly A, and the implementation in B (with a reference to A), you could use A from your mainapp to reference the UserControl.
I don't know whether it would accept a "similar looking" interface from another assembly, even if they have the same name - AFAIK, they'd be treated as different types since they are located in different assemblies.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I second the suggestion of moving the interface definition a .dll shared by the executable and the control library. The interface shouldn't change that often.
Also I wouldn't call the interface Iinterface. IUserControl is probably more fitting.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Thanks for your reply. I'll try it. I used a nonsensical name because I was just pasting in the minimal amount of code, to keep the post brief.
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
Hello everyone,
In one of my project i have a requirement of getting OS Name,version information etc of local network.
Is anyone have any idea of getting Non-Windows OS infomation from Windows machine using c#,c++,or Win32 API.
Thanks in Advance.
Regards,
Jitendra Singh
|
|
|
|
|
A network does not have OS information, it's just a bunch of wires connecting a group of systems. And what exactly do you mean by "Non-Windows OS infomation from Windows machine"?
|
|
|
|
|
If you mean "I want to run software on my Windows machine to find out what OS all the other equipment on my network is running" then AFAIK you can't. Partly because some if it is unlikely to be a computer at all - printers, router, dedicated IoT devices and so forth; and mostly because security on most systems prevents it. If you advertise your OS, then you advertise your vulnerabilities - so it's kept within the machine for the most part to make it harder for attackers. You can guess by checking which ports are open - different OSes tend to open a different set of ports by default, so if they haven't been changed it might be indicative, but it won't be conclusive.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I mean i will provide a IP range that belongs to same local network.
For instance i give IP range 192.168.1.20 to 192.168.1.30
IP OS
192.168.1.20 Windows 7 x64 bit
192.168.1.21 Linux OS
192.168.1.22 Mac (Lion 10.7) x64 bit
192.168.1.23 Windows 7 x32 bit
I hope now the picture becomes more clearer.
Regards,
Jitendra Singh
|
|
|
|
|
And as I said: AFAIK, you can't do that.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The only way that springs to mind depends on you having these machines running under Active Directory, with none Windows machines connecting to AD via Samba. If you have this, you can retrieve the details about the OS using AD services.
|
|
|
|
|
I've outsourced my enterprise level project to a freelancer and I got a quite good setup too. But now that contract has finished and the person has also moved to a new technology, in other words not willing to extend the contract. Now I'm looking into this code on myself. I do have a 2 3 years of background in C# and MVC. Below is a rough idea of my application architecture. Hopefully I've tried my best to abstract the architectural details of an enterprise level application. Please let me know if you need further brief on any of the questions.
All my Entities are defined as C# POCO classes as:
public class Product : BaseEntity
{
public int ProductId { get; set; }
public string ProductName { get; set; }
}
Now I've a IDbContext like as :
public interface IDbContext : IDisposable
{
IDbSet<TEntity> Set<TEntity>() where TEntity : BaseEntity;
}
Base Entity is a Partial POCO class that each POCO entity is inheriting. Here is a class that implements this IDBContext as:
public class MyObjectContext : DbContext, IDbContext
{
public new IDbSet<TEntity> Set<TEntity>() where TEntity : BaseEntity
{
return base.Set<TEntity>();
}
}
Now I've defined a IDbContextFactory that is responsible for providing the DBContexts as :
public interface IDbContextFactory
{
Lazy<IDbContext> CreateDbContext();
}
The class implementing this IDBContextFactory interface is having below structure :
public class MyDbContextFactory : IDbContextFactory
{
public MyDbContextFactory(string dbConnectionString)
{
_dbConnectionString = Settings.DbConnectionString;
_dbContext = CreateDbContext();
}
public IDbContext CreateDbContext()
{
IDbContext dbContext = new IDbContext(() => CreateNewContext());
return dbContext;
}
private MyObjectContext CreateNewContext()
{
return new MyObjectContext (_dbConnectionString);
}
}
Here IRepo Pattern comes into role as:
public partial interface IRepository<T> where T : BaseEntity
{
T GetById(object id);
}
Now the Repository class implementing this Interface is as below :
public partial class EfRepository<T> : IRepository<T> where T : BaseEntity
{
private readonly Lazy<IDbContext> _dbContext;
private readonly IDbContextFactory _dbContextFactory;
private readonly Lazy<ObjectStateManager> _objectStateManager;
public EfRepository(IDbContextFactory dbContextFactory)
{
_dbContextFactory = dbContextFactory;
_dbContext= _dbContextFactory.CreateDbContext();
_objectStateManager= new Lazy<ObjectStateManager>(() => ((IObjectContextAdapter)_dbContext.Value).ObjectContext.ObjectStateManager);
}
public T GetById(object id)
{
return this.Entities.Find(id);
}
}
Till now we are done with the Infrastructure level setup for DB Access Management. Now the thing is to utilize this setup into Controllers(as I'm having directly accessing Repositories from Controllers) to as below :
public CountryController(Lazy<IRepository<Country>> countryRepository)
{
_countryRepository = countryRepository;
}
public Country GetCountryById(int id)
{
Country country = _countryRepository.Value.GetByIdNonProxiedAsync(id);
if (country != null)
return country;
else
return null;
}
Hopefully all above is clear. Now here are the some questions that I need to be answered :
1) Why we are having this layered flow like as:
IDBContext -> IDBContextFactory -> IRepository <T>
and then finally using this IRepository into Controllers for accessing Data objects. In other words why we are relying on Interfaces instead of actual Class Objects while implementing Constructor Injection for Country Controller ?
2) Is this the correct approach for a Enterprise level Application as it should be much scalable for future purpose. If there is any other then I would be glad to know about that ?
3) In Controller's constructor I've used Lazy>, so what's the purpose of this Lazy and is it beneficial actually If yes then in what way ?
modified 29-Jan-15 8:20am.
|
|
|
|
|
Run Run! Watch out for the flamethrower!
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Thanks mate. Please find it out yourself. I posted this question here by mistake. I appreciate your response.
|
|
|
|
|
Amy Dev wrote: public Country GetCountryById(int id)
{
Country country = _countryRepository.Value.GetByIdNonProxiedAsync(id);
if (country != null)
return country;
else
return null;
}
Not to answer your question, but this made me chuckle.
BTW you may want to ask the question in the QA or in the C# forum.
Your time will come, if you let it be right.
|
|
|
|
|
Thanks mate. Nice catch. I posted this question here by mistake. I appreciate your response and I've moved the question to ASP.NET Forum.
Just in case if you are interested then my answer is, I tried to abstract as much complexity I can hide from my code but I forgot this one here. Actually this method is coded as per parallel programming.
|
|
|
|
|
I would like to know which moron thought C++ was better than C. As for Java and C#!
Who needs multiple inheritance when you have copy and paste?
|
|
|
|
|
|
Thanks mate. Nice catch. I wish you continue your these kind of annoying replies.
|
|
|
|
|
|
Thanks mate. I posted this question here by mistake. I appreciate your response and I've moved the question to ASP.NET Forum.
Parallely I'm going through your referenced Link. Really thanks
|
|
|
|
|
Rule 1: Learn to read. At the top of the page, it says: "if you need specific help please ask your question here." and links to the QA forum: http://www.codeproject.com/Questions/ask.aspx[^]
Instead, you posted what looks like your homework in a non-question forum, because you couldn't be bothered to look properly.
Now, what makes you feel that I might want to bother myself and spend time answering your question, when you can't be bothered to ask in the right place?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|