|
What does that mean, they can't use the DLL at the same time? Is it written in some unmanaged code?
There may be a class in there that can only be used by a single consumer at a time, but then you could still reference and load the DLL from two applications.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The DLL is a third party component, there is licensing in it to prevent multiple, simultaneous access.
|
|
|
|
|
Aaah, so you want us to help bypass a license?
How would you react if you saw a similar question here asking the remove the license from a product that you created?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Why can't they access the DLL at the same time?
|
|
|
|
|
The DLL is a third party component, there is licensing in it to prevent multiple, simultaneous access.
|
|
|
|
|
What happens if your applications would access it simultaneously? If it "just" throws an exception and doesn't lock your license or something equally evil, you could implement a simple retry-logic.
Otherwise you could implement a wrapper-DLL that does the synchronizing via a mutex (or semaphore, if it could happen in the future that you upgrade that license to allow X simultaneous accesses).
Mutex class[^]
|
|
|
|
|
You could use a mutex to synchronize access to the DLL.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
do you have an example, or article you can link?
|
|
|
|
|
|
Make a new application (server) that references the 3rd-party dll.
Remove the references to the 3rd-party dll from the other programs(Windows app and service).
Determine how you want the other programs to access the new app (and 3rd-party dll): file directory watcher; message queue; pipes; sockets; remote automation; etc.
Send 3rd-party dll requests from the 2 programs to the new unattended app that handles requests by monitoring a file directory; or message queue; or ...
Results are returned along the same lines.
|
|
|
|
|
Gerry Schmitz wrote: Make a new application (server) that references the 3rd-party dll.
That is what I would suggest as well.
|
|
|
|
|
hi,
i am working on a project in which i need to transfer the data received from a query to multiple labels.
My Query: select make from dbo.cardetails;
the result of the above query is a single column with 30 rows.
now i want each row to be used as Label.text in C#
awaiting ur helpful replies.....
thanks in advance
modified 2-Aug-18 21:02pm.
|
|
|
|
|
Don't.
What if next week someone removes three rows? Or add seven? What happens to your app?
It falls over, is what.
Instead, look at using a grid based control of some form, depending on your working environment. For WinForms, a DataGridView would be good; for a website, maybe a GridView; and so forth.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
hey buddy,
but the database will be in accessable to the users.
they could only use the front end (C# form app).
so if u could help me out with my problem, it would help me alot.
modified 2-Aug-18 21:02pm.
|
|
|
|
|
If you want to make it flexible and avoid what Griff is saying you are going to need to be able to create these labels at runtime using something similar too
Label MakeLabel = new Label();
MakeLabel.Name = "x";
MakeLabel.Text = CardDetailsField;
Form.Controls.Add(MakeLabel);
please note that this code snippet is not complete as you need to add the looping of your resultset, positioning on the form etc.
But also Like Griff stated can't you use something different to display the data? such as a datagridview or listbox control?
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
thanks for ur code Simon
it worked good
but the problem is tat my Labels are already present and only their names are to be assigned such tat i cud change the db in future to avoid much work and the labels get new names as soon as the db is changed and run.
modified 2-Aug-18 21:02pm.
|
|
|
|
|
hi,
i want to decompile SWF file from c#. my version is 9. any can help me in this
|
|
|
|
|
krvasanth wrote: any can help me in this Start here[^].
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|