My.Settings Questions

[Mike]

"It works like VB6"
I assumed that this referred to the "my.Settings" reference in the above
line, and I asked
"It works like what in VB6?"
because I didn't know of anything in VB6 that worked in a way that was
like My.Settings. If this statement was meant to be helpful, why not let
us in one the secret of which part of VB6 works like My.Settings?

Like I mentioned in my response to Cor's "it works like VB6"

I never used this at the VB6 level...

what I did used in the past for our only VB6-based add-on product was
using the Win32 Private Profile API in INI mode.

So when Cor stated that, what resurfaced in my mind was the possible
connection to the MSDN documentation statement that My.Settings was a
"Compatibility module" and that was probably what Cor meant. i.e.
My.Settings replaces PrivateProfile with an XML storage method and/or
VB.NET had a similar MFC application class that wraps the Private
Profiles API.

But the usage is different and the question pertain to what amounted
in my mind to sharing the same process "My" namespace between the EXE
and DLL. (See technical note below).

In the final analysis, is that the same process user's local setting
storage location is used, however, the section used for each is separated:

So what you end up having is:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="userSettings" ... >
<section name="YOUR-PROCESS-EXE.My.MySettings" ... />
<section name="YOUR-DLL.My.MySettings" ... />
</sectionGroup>
</configSections>
<userSettings>
<YOUR-PROCESS-EXE.My.MySettings>
... settings names and values ...
</YOUR-PROCESS-EXE.My.MySettings>
<YOUR-DLL.My.MySettings>
... settings names and values ...
</YOUR-DLL.My.MySettings>
</userSettings>
</configuration>

and this is stored (in User Scope):

%USERPROFILE%\Local Settings\Application Data
\COMPANY_NAME\YOUR-PROCESS-EXE_GUID\VERSION
user.config

Regarding the Sharing of namespace:

Ok, this is where I probably "over thought" that VB.NET provided
inherent support for Global Shared Memory of "MY" between all .NET
assemblies. My suspicion that it does for its own .NET purposes.

But at the application level, you have to role your own and this is
the same in all other languages. So if you wanted to share memory
created by a DLL or EXE you either have to compile the same RDATA
segment name or used a memory map using WIN32 API functions:

CreateFileMapping() (server uses this)
OpenFileMapping() (client uses this)
MapViewOfFile() (server/client uses this)


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.

--

 

[Mike]

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>

 

[Cor Ligthert[MVP]]

Michel,

With "it works like VB6" I did never mean "it works like in VB6".

I know that it is easy to use, however persons here busy with VB Net from
2002 where not really happy with it.

It is not really OOP but using classic programming and therefore makes from
VB Net a little bit as it was in VB6

In those days there were many discussions in the dotnet newsgroups if VB Net
was a real mature OOP program language.

But who cares today, those discussions are over.

It has standard no counterparts in the other managed languages and it seems
that it is as well not wanted in those.

Cor

 

[Cor Ligthert[MVP]]

See my reply to Michel

I have not commented on anything other then your posts. You made two
statemenets:
"The my.Settings is build to make a bridge between VB6 users and Net"
I have no idea what that means and I ignored it.

"It works like VB6"
I assumed that this referred to the "my.Settings" reference in the above
line, and I asked
"It works like what in VB6?"
because I didn't know of anything in VB6 that worked in a way that was
like My.Settings. If this statement was meant to be helpful, why not let
us in one the secret of which part of VB6 works like My.Settings?

You responded with:
"You don't need to instance an object to use this, it is completely
shared.

"Some VB6 users showed that they did not understood the difference between
a
class and an object."

I attempted a translation of that first statement (which I am happy to
have corected if I got it wrong) and I noted that the second comment was
irrelevant, which it is.

You now tell me that:

"It is expressly for that reason not in C# or in managed C++ or in managed
F#"

I think you are saying that the My.Settings functionality does not exist
in those languages because some VB6 users cannot distinguish between a
class and an object (which I read as "between a class and an instance of a
class") which I suppose derives from some inside knowledge you have of how
the product design teams think. Regardless, it is just as irrelevant as
your orignal reference to VB6. If you are trying to make some point that
assists OP in resolving the issue, please do so without this political
grandstanding.

 

[Mike]

Michel,

With "it works like VB6" I did never mean "it works like in VB6".

I know that it is easy to use, however persons here busy with VB Net
from 2002 where not really happy with it.

It is not really OOP but using classic programming and therefore makes
from VB Net a little bit as it was in VB6

In those days there were many discussions in the dotnet newsgroups if VB
Net was a real mature OOP program language.

But who cares today, those discussions are over.

It has standard no counterparts in the other managed languages and it
seems that it is as well not wanted in those.

Cor

Not sure how this correlates to using My.Settings between a EXE and DLL?

I guess maybe I do, but we are talking VB.NET and not VB6.

In any case, my near final solution is:

1) Create the project settings in the DLL windows form

2) Use PropertyBinding to bind the form fields with
the DLL my.settings namespace

3) Used a Partial Class with Nested class with a default
property to access My.Settings

Partial Class WildcatLoginForm
Public Settings As New LoginSettings
Public Class LoginSettings
Default Property Self(ByVal name As String) As Object
Get
Return My.Settings(name)
End Get
Set(ByVal value As Object)
My.Settings(name) = value
End Set
End Property
End Class
End Class

Probably more direct ways but this reduced the code avoiding to create
a property for each field and the EXE now has access to the fields
using properties:

Session = New WildcatLoginForm
Session.Settings("name") = value

Before this last version, where I add each field as a get/set property
which I might go back to once I learn how to use ApplicationSettingsBase.

Its all good Now.

--

 

[Michel Posseth [MCP]]

Mike

I use this in my projects this gives you the ability to ship dll specific
config files with your project


Imports System.Configuration
Namespace My
Partial Friend NotInheritable Class MySettings
Private DllSettings As ClientSettingsSection
Private DllConfigDoesNotExist As Boolean
Default Public Overrides Property Item(ByVal propertyName As String)
As Object
Get
Dim oValue As Object = Nothing
Try
'If the .dll.config file has already been loaded, use it
to obtain the value...
If DllSettings IsNot Nothing Then
oValue =
DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml
ElseIf Not DllConfigDoesNotExist Then
If Me.LoadDllConfigFile() Then
oValue =
DllSettings.Settings.Get(propertyName).Value.ValueXml.InnerXml
End If
End If
Catch ex As Exception
End Try
Try
If oValue Is Nothing Then
oValue = MyBase.Item(propertyName)
End If
Catch ex As Exception
End Try
Return oValue
End Get
Set(ByVal value As Object)
MyBase.Item(propertyName) = value
End Set
End Property
Private Function LoadDllConfigFile() As Boolean
Dim bDllConfigLoaded As Boolean = False
Dim cfgDll As System.Configuration.Configuration
Dim cfmDllCfg As New ExeConfigurationFileMap()

Dim sAssemblyPath As String =
Reflection.Assembly.GetExecutingAssembly().Location

Dim strNamespace As String = GetType(MySettings).FullName
strNamespace = strNamespace.Substring(0,
strNamespace.IndexOf("."c))


cfmDllCfg.ExeConfigFilename = sAssemblyPath & ".config"
Try

cfgDll =
ConfigurationManager.OpenMappedExeConfiguration(cfmDllCfg,
ConfigurationUserLevel.None)

Dim csgApplicationSettings As ConfigurationSectionGroup =
cfgDll.GetSectionGroup("applicationSettings")
Me.DllSettings =
DirectCast(csgApplicationSettings.Sections(strNamespace & ".My.MySettings"),
ClientSettingsSection)
bDllConfigLoaded = True

Catch ex As Exception

'bestaat niet
DllConfigDoesNotExist = True

End Try
Return bDllConfigLoaded

End Function

End Class

End Namespace

 

[Michel Posseth [MCP]]

I was a bit to quick with posting the reply

usage :

set a reference to system.configuration , include the code file in your
projects now these projects can aquire the settings from there own config
file if called by a exe
this was the bit of extra coding i was refering to in my initail answer

HTH

Michel

 

[James Hahn]

I don't understand the reference to shared memeory. In .Net all
communication between the EXE and DLL will be by properties that each
exposes or parameters passed in methods (including constructors). You may
have been misled by the reference to VB6 - My.Settings is not even vaguely
similar to anything in VB6, and it is certainly not global.. I would not
contemplate using some feature of the My namespace to provide a form of
shared access. There just doesn't seem to be any point, even if you could do
it. The DLL is going to be invoked by the application - it should not need
to look back into application or user settings for its parameters - they
should be passed in whatever call invoked the function in the DLL, or by
properties of the DLL that were set by the applcation before it invoked the
function. That's the .Net way.

 

[Mike]

Thanks. I plan to see how it works in the next few days.

 

[Cor Ligthert[MVP]]

James,

You may have been misled by the reference to VB6 - My.Settings is not even
vaguely similar to anything in VB6, and it is certainly not global..

You mean you can use it everywhere in an application but it is not global
usable.

Ah now I understand a lot.

Cor

 

[James Hahn]

That's correct. The My.Settings values are available anywhere in the
application, but they are specific to the application (and the user) and are
not available globally, for instance from the DLL. That's why OP had to
take special steps to access the application My.Settings from the DLL
(which, IMHO, would have been better done by exposing properties or passing
parameters). You will find a good description of My.Settings in MSDN - you
may wish to start here:
http://msdn.microsoft.com/en-us/library/ms379611(VS.80).aspx

 

[Mike]

James,

I wasn't misled by Cor. Whether My.Settings was "like" in VB6 or not
was besides the point because it didn't answer the question. I
clearly knew it wasn't the same, but I did give him the benefit of the
doubt that it was like MFC ala CWinAPP application class, that uses
private profile wrappers for INI or Registry storage depending on the
mode you choose. But as others pointed out, importing the private
profile functions would be necessary in VB6.

The "ah ha" for me (and I am sure it would be for many) is that the
storage is in the same file but different nodes (sections) in the XML
document and it is stored under the user's application local setting
folder - all by default using the LocalSettingsProvider.

Once realized it was easy to self-contain the fields (as I wanted) in
the default section for the DLL assembly and as I outlined they were
exposed via a default property in the DLL class. It seems you skimmed
over what I wrote Last small point, sure, its the .NET way, but in
reality it is the .DLL way.

If anything to be gained, as I also noted, is a possible enhancement
to allow a more declarative reference to a new object:

My.Application.Settings <---- Process NameSpace Storage
My.Settings <---- Current Assembly Namespace Storage

That would be, in my opinion, "easier" for the RAD VB developers and
would wrap the RoamingUser (initially viewed as a bad terminology as
that has a specific meaning in other technologies) concept for
configuration.