|
The terse descriptions here apply to WinForms "classic," not WinForms "Core," which I have found unusable, so far.
It's easy to write a Windows Class Library that compiles into a .Dll. I can put a static Class in that code, and declare methods with void or return types, or even Extension methods.
Using that .DLL in a new WinForms app project is easy:
// assuming thew Dll is named ",,, / TestDLL1
// in the WinForms project which has a reference to TestDLL1
// where the static class in TestDLL1 is named: TestDLLExtension
using static TestDLL1.TestDLLExtension;
Now: what I can't achieve.
1) I write another Class library, named 'ExtensionsLibrary,' that has a reference to TestDLL1
2) I now add a reference to the ExtensionsLibrary DLL tto the WinForms project.
3) the WinForms project has the refrencee to TestDLL1 removed.
I can't find any way to use 'using that allows me to access/use the static methods in TestDll1 referemced by ExtensionsLibrary.
In other words, I cannot achieve an "outer" DLL that has referrences to other, "inner," DLL's.
Perhaps my error is in thinking this is possible ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
For NuGet references, pulling in package A will also pull in all transitive dependencies of package A:
NuGet Package Dependency Resolution | Microsoft Learn[^]
For assembly references, that doesn't happen. If your project references assembly A, but not assembly B, you won't be able to use any of the methods defined in assembly B. And if you call any methods in assembly A that (directly or indirectly) rely on assembly B, you will get a run-time exception unless assembly B can be located. (eg: The assembly is deployed to the output directory, or the assembly is installed in the GAC.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks, Richard. What I am describing does not use NuGet: it has never occurred to me to try and load a DLL via NuGet ... if that is what you are suggesting.
In this case, assembly A (DLL) has a reference to assembly B (DLL), and a "using static" using statement to the static class in B.
The WinForm app has a reference to A, and I am seeking to call static methods in B from A.
If that is not possible, okay.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
BillWoodruff wrote: If that is not possible, okay.
Correct. As I said, assembly references don't automatically pull in transitive dependencies, so your WinForms app doesn't actually have a reference to B.
I've largely switched to using a private Azure DevOps NuGet feed[^] for cross-solution dependencies. It means other developers can work on my projects without needing to have the correct versions of the referenced assemblies in the same physical or relative path, as well as ensuring that transitive dependencies are always pulled in.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks, agaib !
As I said to Griff: "You can always make one DLL with multiple static classes, and reference/expose whichever ones you desire ... so my question is kind of academic."
Re your use of NuGet and Azure: fascinating; I'm kind of ... by choice ... still using older non-web simple stuff, like WinForms ... other non-technical priorities in my life, now, like staying alive 
Re your signature with quote from Homer: if you happen to be interested in the "mind of Homer," I can send you a link to the most remarkable essay (introduction to a newer translation) on the Attic context out of which Iliad, and Odyssey arise.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
BillWoodruff wrote: Re your signature with quote from Homer
Wrong Homer.
Quote: Marge: Homer, a man who called himself "you-know-who" just invited you to a secret "wink-wink" at the "you-know-what". You certainly are popular now that you're a Stonecutter.
Homer: Oh, yeah. Beer busts, beer blasts, keggers, stein hoists, AA meetings, beer night. It's wonderful, Marge. I've never felt so accepted in all my life. These people looked deep within my soul and assigned me a number based on the order in which I joined.
Homer the Great[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Oh, that Homer
I nominate this exchange with you for "CP Surreal Posts of the Year."
p.s. once you study moods in Homeric Greek, indicative, imperative, interrogative, conditional, and subjunctive ... neurons are ... permanently altered. it took me years to forget them.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 9-Jan-23 9:12am.
|
|
|
|
|
The using statement establishes a "shortcut" alternative to using the full name of a class: "Form" instead of writing "System.Windows.Forms.Form" each time you want to use it.
It doesn't add a namespace to the project - to access those you need to have a refence to the containing assembly.
Your ExtensionsLibrary assembly is already built with the reference it needs (and every assembly that uses ExtensionLibrary will need access to the TestDLL1 assembly file in order to work) but that doesn't include the subassemblies when you add a reference to it, so using doesn't "know" where to point the shortcut - any more than you can use the full name of a class and the system can work out which .DLL or .EXE file contains it.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
modified 9-Jan-23 4:56am.
|
|
|
|
|
Thanks, Griff,
imho, "using static" is kind of a different beast: it sure works fine to expose the public static class in a referenced DLL, and its methods ... the "simple" use case I describe first.
If a "nested" DLL ... the second example ... is not referenceable, not a problem.
You can always make one DLL with multiple static classes, and reference/expose whichever ones you desire ,,, so my question is kind of academic.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
To illustrate why my question is academic, and, how simple it can be to have multiple static classes in one DLL, and expose your choice of them and their methods, I offer a terse example:
1) create a WinForm class library with multiple static classes and public static methods: TestDLL_1_1_2023
2) compile it
3) in a WinForm app: reference the compiled DLL.
4) use "static using" statements to expose your choice of methods:
// expose string methods
using static TestDLL_1_1_2023.StupidStringExtensions;
// do not expose numeric methods
// using static TestDLL_1_1_2023.StupidNumericExtensions;
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
i create dynamic textbox and button save app windows form, but i can't insert data to dynamic textbox after i create event button click save
private void Createtextbox()
{
TextBox textboxUsername = new TextBox();
textboxUsername.Location = new Point(420, 50);
textboxUsername.Size = new Size(500, 30);
textboxUsername.Name = "text_user";
System.Web.UI.WebControls.RequiredFieldValidator rq = new System.Web.UI.WebControls.RequiredFieldValidator();
rq.ErrorMessage = "Error is for Dynamic Control";
rq.BorderColor = Color.Red;
rq.ControlToValidate = "DynControl";
this.Controls.Add(textboxUsername);
TextBox textboxPassword = new TextBox();
textboxPassword.Location = new Point(420, 80);
textboxPassword.Size = new Size(500, 30);
textboxPassword.Name = "text_pass";
this.Controls.Add(textboxPassword);
TextBox textboxMail = new TextBox();
textboxMail.Location = new Point(420, 110);
textboxMail.Size = new Size(500, 30);
textboxMail.Name = "text_mail";
this.Controls.Add(textboxMail);
Button btnSave = new Button();
btnSave.Location = new Point(420, 150);
btnSave.Name = "Submit";
btnSave.Size = new Size(80, 26);
btnSave.Click += new EventHandler(btnSave_Click);
this.Controls.Add(btnSave);
}
private void btnSave_Click(object sender, EventArgs e)
{
try
{
if (this.ValidateChildren())
{
//Here the form is in valid state
//Do what you need when the form is valid
TextBox textboxUsername = (TextBox)sender;// textboxUsername not instal
}
else
{
var listOfErrors = this.errorProvider1.ContainerControl.Controls.Cast<Control>()
.Select(c => this.errorProvider1.GetError(c))
.Where(s => !string.IsNullOrEmpty(s))
.ToList();
}
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
|
|
|
|
|
The sender parameter is the control that raised the event - which for a button Click event would be a Button not a TextBox. Since the Button and TextBox controls do not inherit from each other, you cannot cast from one to the other, any more than you can use an Apple like an Orange although they are both Fruits.
Your TextBox called textboxUsername is local to the Createtextbox method, and can't be accessed outside it except by going via the Controls collection and finding the specific control.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
What are my options for securing a named pipe conversation so that only my client application can communicate with the Windows service server?
If I use a security descriptor, would that limit pipe access by user, or could it be used to limit pipe access to only my application?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
is there a reason you don't look for, and study, recent articles like this: [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I thank you for the reply.
Does this article give insight into how to secure the data passing over a named pipe so that only my application can read it?
I can say that the main reason I didn't look for that article is that it's not relevant to my question.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Message Closed
modified 4-Jan-23 4:59am.
|
|
|
|
|
I never said any of that. If this question is a waste of your time, then don't reply.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I assume that you will be using streams ... you could use the CryptoStream Class (System.Security.Cryptography) | Microsoft Learn[^] to encrypt & decrypt. If you google, you will find examples on how to do it if the MS examples are not enough.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Ahh! Thank you Graeme. That's the kind of pointer/tip I was looking for.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Cryptography secures what's "in the pipe"; it doesn't "secure the pipe". You're back to Access Control.
Named Pipe Security and Access Rights - Win32 apps | Microsoft Learn
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Very good point. Thank you. I am more interested in securing what's in the pipe. I want it so that even if someone can connect to the pipe, they won't be able to make sense of what's going back and forth.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
jschell wrote: Thread here suggests that more might be needed.
SSL is a CryptoStream.
What you don't have is authentication.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Hmmm,
You haven't really given enough information but I think you are wanting to:
- Have an application read/write over a named pipe.
- Prevent the application user from accessing the named pipe. (Essentially securing or isolating the information/pipe from the user)
If I were asked to do this I would use a DLL Surrogate and have the Custom Surrogate process open and manage the named pipe. This would allow you to have some security separation between the application users and surrogate process.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
