My.Settings Thoughts

Mike wrote:

In other words, I thought "My" with its nested objects:

My.Application
My.Computer
My.Settings
My.User

was a GLOBAL shared memory map that allowed the EXE and her .NET dlls to shared this "namespace"

At this point, I get the idea that it might be sharing, but there are other things you need to prepare (security wise) to allow it to happen. But for the settings, it uses the same file, but the sections are different.

There are probably all kinds of implementations ideas going on here, but the purpose of single sourcing your code, I see some architecture notes here that is helpful:

Application Settings Architecture
http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx

I added the example code into my DLL class:

Public Class MyUserSettings
Inherits ApplicationSettingsBase
<UserScopedSetting()> _
<DefaultSettingValue("True")> _
Public Property UseAutoLogin() As Boolean
Get
return Me("UseAutoLogin")
End Get
Set(ByVal value As Boolean)
Me("UseAutoLogin") = value
End Set
End Property
End Class

And now I can use this a common class in the process itself. I am currently reading the section on "Settings Persistence" regarding the SettingsProvider.

Note: I already have a working solution so all this is more exploring whats there. For example, I had manually add properties to set/get the form fields but now I see it was already provided via:

Property Binding

To provide access to the EXE, I had created Get/Set properties (like above) but I did that in the Form partial class. With Property Binding I can now remove this redundant code. But I see this does not expose the property to the EXE so I think I prefer to keep the properties I added but this time add them to an inherited ApplicationSettingBase class so I can get access other class features, like Save() which was also manually added to the form partial class.

Ideally, what would useful and I believe a natural logic and declarative (layman coding) for RAD developers is extension to the My.Application object like

My.Application.Settings

That way it can be used by the application DLLs.

Anyway.... <g>
.

Relevant Pages

  • Re: VS2005 and isolated apps.
    ... For the exe and DLLs, ... linker settings, as well as at the top level of properties. ... If they worked reliably right out of the box, manifests sound like ...
    (microsoft.public.dotnet.languages.vc)
  • Re: VS2005 compatibility
    ... Paul T. ... I know the Link have the Heap and Stack memory settings. ... The EXE could really be bad. ... You say "I can download the program to the target device to run ...
    (microsoft.public.windowsce.app.development)
  • Re: Asus V9250 magic graphics driver - cant see adaptor in Contro
    ... This is a painstaking procedure as there are a lot of dlls and ... exe files to open in depends. ... only created on successful install which hasn't happened. ... driver inf file. ...
    (microsoft.public.windowsxp.embedded)
  • Re: C# Exceptions
    ... I did a runtime analysis of the exe and some important DLLs as ... > signature is valid then the app can decrypt the response and process it. ... > the source code of a managed app. ... NOT FOR THE MAIN PROGRAM EXE FILE. ...
    (Pen-Test)
  • CWinApp Assertion failure/ Access violation in odbc32.dll
    ... What I’m seeing in the debugger: Before the .EXE reaches the main ... DLLs that are linked implicitly to our .EXE modules. ... In the GenUtil class an instance of FileUtil is created. ... The ASSERTION failure seems to occur when the FileUtil Constructor is called ...
    (microsoft.public.vc.mfc)
Loading