|
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.
|
|
|
|
|
Your guess is spot on.
I'm glad you responded. Writing a native COM server might be slightly beyond my knowledge scope, but it probably depends upon exactly how secure I need the pipe's contents to be.
The information would be proprietary in nature, but it wouldn't be sensitive like personal user data.
I will consider this as a possibility. Thanks.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard,
It's much simpler than you can imagine. I can't think of any other way to accomplish your goal. What you are trying to achieve is less than 12 hours of work with a DLL surrogate. I can't remember off the top of my head if there were old code samples in the Windows SDK. I'm on a brand new workstation I built for Christmas so I don't even have my dev environment setup yet.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
