I have a Boolean, user scoped setting. I access it through a referenced class library, called Settings. This class library has a Module with properties:
Module AppSettings
Public Property MyBooleanSetting() As Boolean
Get
Return My.Settings.MyBooleanSetting
End Get
Set(ByVal value As Boolean)
My.Settings.MyBooleanSetting = value
My.Settings.Save()
End Set
End Property
End Module
I defined the setting in the Property pages of the Settings class library.
When other code manipulates the setting it will use code like:
Settings.MyBooleanSetting=True
While the code is running this works. But after a restart of the application the new value is not persisted.
Where am I going wrong?
After looking at the Using My.Settings in Visual Basic 2005 MSDN article and these MSDN Forum Threads , I would say you need to verify which path is being used.
User-scope settings are specific for each user. They can be read and set safely by the application code at run time. These settings are stored in a user.config file. To be technically accurate, there are two user.configs per user per application—one for non-roaming and one for roaming. Although the Visual Basic 2005 documentation states that the user.config file will be named according to the user's name (joe.config), this is not the case. The user.config file is created in the \[Local Settings]Application Data\\\. Where:
• is the user data directory, either non-roaming (Local Settings above) or roaming.
• is the user name.
• is the CompanyNameAttribute value, if available. Otherwise, ignore this element.
• is the AppDomain.CurrentDomain.FriendlyName. This usually defaults to the .exe name.
• is the URL, StrongName, or Path, based on the evidence available to hash.
• is a SHA1 hash of evidence gathered from the CurrentDomain, in the following order of preference:
a.StrongName
b.URL
If neither of these is available, use the .exe path.
• is the AssemblyInfo's AssemblyVersionAttribute setting.
Save your breath guys. The code did work after all. I used an other Property in the Viewmodel of my application that cached the Setting.MyBooleanSetting, but I forgot to read it in at application startup...
Related
I built a virtual filesystem (not a namespace extension) for Windows which acts as a frontend of our document management server consisting of files and folders. In order to be able to display some metadata of the DMS objects in Windows Explorer as additional selectable columns, I successfully provided properties to the Windows Property System by implementing a COM Property Handler. Wheras normal property handlers focus on specific file types for which they feel responsible, my Property Handler adds properties to all files regardless of their type. Because Property Handlers can only be registered on the file type level, I registered my handler for about 30 types under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\<.Extension>
However, I did not manage to register the Property Handler for folder objects. Since all objects in our file system are virtual I build the property store (IPropertyStore) by implementing IInitializeWithFile instead of IInitializeWithStream. The properties are requested from our DMS with the path of IInitializeWithFile acting as key and were not read from an objects content. This concept would work for folders as well.
For getting called on folders I tried to associate the handler by registering under different well known identifiers like Folder, Directory, AllFileSystemObjects and * instead of the file extension without success.
I also didn’t find anything in the MSDN documentation regarding this aspect.
Is there a way to register a Windows Property Handler on folders? Or is there some other way to add custom columns to folders in Windows Explorer?
I'm not sure if it is possible to do this.
Property handlers are clearly not the right approach, they are system wide and there can only be one per file extension. They should only be implemented by the software that "owns" the file extension and can parse the file to extract properties.
The old column handlers would have been your best bet (IMHO) but they are officially dead and you already said you can't use them.
Have you considered creating a namespace extension? Either as a root item somewhere (Desktop or My Computer) the way My Documents used to work in 2000/XP or maybe something more along the lines of how OneDrive works?
I'm not sure if desktop.ini files work in the root of a drive but it might be worth looking into. You would then find yourself in the poorly documented land of [.ShellClassInfo] and its CLSID, CLSID2 and UICLSID members. The general idea would be to act as a IShellFolder proxy on top of the "real" IShellFolder so you could create a multiplex property store. I think there are some (undocumented?) property keys you can override to change the folders default columns and tooltips as well.
There is also something called a delegated folder that allows you to play with nested PIDLs but the documentation is once again pretty useless so I'm not sure if this is something worth looking into.
A 3rd option is to pretend to be a cloud storage provider. I don't know if this gets you any closer to your goal and you would still have to implement some NSE bits to get to the point where you can layer yourself on top of the underlying IShellFolder. This feature is rather new and only documented to work on Windows 10.
The inner workings of how Explorer/IShellBrowser is connected to the IShellFolder/IShellView is one of the least documented parts of Windows. There are hundreds of undocumented interfaces. Explorer gives DefView special treatment leaving other 3rd-party implementations out in the cold.
My feeling is that there is no clean solution to implement this on top of a drive letter but you might get lucky, if Raymond Chen drops by he might have some tips for you...
I know that local.Properties overrides project.Properties.
I also know that that these files define… database connections, ports, build environment, frontend HTTPS, etc.
I further know that project.Properties contains more properties.
Will appreciate if Hybris experts tell me syntax of local.Properties, illustrating with some example.
Please provide correct info.
If we talk about the syntaxes of entries in the project.properties file, then it is key=value
The property files in the hybris are of two types:
The extension level - The property file project.properties is the configuration file that carries properties in the key-value pair for the configurations involved on the extension level For instance, Consider a property in the project.properties of the yacceleratorstorefront (storefront template) extension storefront.storelocator.pageSize.Desktop=10 which clearly indicates the 'StoreLocator' results page size configuration per store. Since the store locator functionality is specific to the storefront and has no relevance for the other modules (like core, facades etc), the property is kept at the extension level.
Please note, project.properties reside in the extension folder
The global level - This is the property file which is the global configuration file, and deals with the properties are extension agnostic and carry a global impact. For instance the property commerceservices.default.desktop.ui.experience=responsive sets the ui experience to responsive mode that specifies the deployment to be for the responsive format.
The local.property file supersedes all of the properties with the same key that is defined in any of the project.proprties.
Please note, the local.properties file reside in the hybris/config folder
The hybris registry creates a property configuration map which constitutes all of the properties mentioned in the deployment configuration. The same could be managed in the HAC under platform/configuration.
The clear intent of the local.proprties file is to have information which either requires to be overriden on a global level. The override may be of different types, e.g. cart expiry time could be made different on different environments by the use of the local.property files.
For further reading, please refer to the link: https://wiki.hybris.com/display/release5/Configuring+the+Behavior+of+the+hybris+Commerce+Suite
property call hierarchy (from primary to secondary):
java -Dproperty.key=something
hybris/config/local.properties
hybris/*/(extension-name)/project.properties
hybris/bin/platform/project.properties
and within java code:
configService.getString("property.key", "last fallback value, if no propertyfile provide this key");
You could review all current variables using the hac interface for properties: http://localhost:9001/platform/config
If I have a class library with an app.config file (I know it's not ideal, just bear with me for a moment) which has settings values created by using the projects Settings tab and accessed like this:
Public Shared Function GetMySetting(key As String) As String
Dim value As String = My.Settings.Item(key)
If value = String.Empty Then value = "Setting " & key & " not found."
Return value
End Function
I then retrieve the settings from an application like this:
sb.AppendLine("GetMySetting: " & Library.Settings.GetMySetting("SettingC"))
The settings from the app.config file of the library project are definitely not copied into the app.config file of the application but I can still retrieve the My.Settings from the libraries app.config.
So I added a GetConfigFileName function to the library:
Public Shared Function GetConfigFileName() As String
Return AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
End Function
and retrieved it in the application:
sb.AppendLine("Library Config File: " & Library.Settings.GetConfigFileName)
but that returns the application's config file.
How can I determine which .config file the library is reading from when it calls My.Settings...?
Or are they compiled into the DLL?
but that returns the application's config file. How can I determine
which .config file the library is reading from when it calls
My.Settings...?
By default, it will be always the main.exe.config.
Take a look at this for detailed answer
C# DLL config file for
more informations
You can use external config files. This article on MSDN
explains how.
EDIT
You're misunderstanding the situation, reread this line: The settings
from the app.config file of the library project are definitely not
copied into the app.config file of the application but I can sti retrieve the My.Settings from the libraries app.config.
You are correct. Your settings in the dll.config will not be copied automatically in the app.config.
Concerning the value that you are able to get from your dll, I am still looking for more official answer, but the answer seems to be:
the 'old' values (the ones you define at development time) are hard coded. If the
franework isn't able to access or open the config file it will use the defaults
instead. This will always happen if you use settings in a dll.
Take a look at this Settings.Default.<property> always returns default value instead of value in persistant storage (XML file)
Edited after reading comments.
I think I see what your after. The My.Settings will used the compiled values from your class libs settings as default values. I believe these are compiled in. You can reflect the source though to see if it is setting a defaultvalue attribute on them.
You can override these by setting the values in the main exe's application file. If the settings aren't in the exes file, then you will use the default ones you specified in your class libs.
You shouldn't care about the file name. Just assume the settings are either defaulted or were overridden. If you need to know if they were overridden, that's another issue.
I have a dll which is installed with the initial installation of my app (via an msi file). The dll contains a user key and this is 'demo' for the initial installation. When a user buys a licence he is provided with another dll which contains his name. The second dll is simply the first, rebuilt with a different name so it is the same GUID and file name.
This works fine on my win7 test machine, I can replace the dll in my apps dir and it runs correctly. I have recently provided a user dll to a new client but the replace method doesn't seem to work. He is quite IT literate so I think he is following the emailed instruction (replace the userdata.dll in your app directory with the attached) it does not seem to change the dll. He is using Win8(pro).
I had thought of sending him an Inno setup to copy the user dll into the app dir, Flags:ignorereversion regserver sharedfile
Can anyone suggest a solution or an explanation?
Later...
I have now sent him an Inno setup for the updated dll and this works. If I used the second dll method (a good idea) I would still need to have the user install it.
Rather than replacing the original .dll, why not provide a second .dll with the customer's specific info? The 2nd .dll will unlock features in the original .dll.
For instance, in your original .dll you might check for Customer.dll:
if(TryLoadAssembly("Customer.dll", out assembly)) {
if(Validate(assembly)){
IsUnlocked = true;
}
}
Further recommendations (and untested samples) - have Customer.dll contain a single object implementing an interface:
class Customer : IToken {
GUID Guid {get;}
// other fields
}
To validate:
bool Validate(Assembly assembly){
Type type = assembly.GetType("Customer");
IToken customerToken = (IToken)Activator.CreateInstance(type);
// check some properties
return customerToken.Guid == application.Guid;
}
You say it doesn't appear to be replacing the DLL. Is it UAC redirecting his filecopy into local storage?
If this is the case then the easiest way to deal with it would be to either
1) supply a batch file that can do the file copy, along with instructions to launch the batch file by right clicking on it anc choosing "run as administrator".
2) supply an executable that can do the file copy. You can either include instructions to run the exe as an administrator like the batch file, or you can include a manifest with the application to instruct windows that the file needs to execute as an administrator.
A last option, which might be worth while for troubleshooting would be to get the user to turn off UAC and try the file copy again. If that works then this user will be happy and you know what the problem is and can find an elegant solution for future customers.
I've just looked on my Win 8 laptop and the option for UAC is in Control Panel - User Accounts - User Accounts - Change user account control settings. This will give a slider which can be slid all the way to the bottom to turn off UAC.
(User Accounts really is listed twice.)
I have an MFC application that exposes a bunch of OLE objects for the application, and open documents.
I can connect to the server using the GUID of the application class (e.g.: in ruby for windows: WIN23OLE.new('{12345678-1234-1234-1234-12345678}')) but when I try to connect using the class name WIN32OLE.new('MyApp.Application'), it always fails with "Invalid Class String" error (HRESULT error code:0x800401f3). The same thing happens
There are no errors returned by the OLE initialisation in the MFC app, and once a connection is made by GUID, then it works fine.
I'm just really curious why the class string approach isn't working. Any ideas?
The class string is called a ProgID (short for programmatic ID), and it's really just a human-readable version of the ClassID. ProgIDs are stored in the registry under HKEY_CLASSES_ROOT, for example picking one at random from my registry:
HKEY_CLASSES_ROOT\Microsoft.XMLDOM
Under this key there is another key called CLSID:
HKEY_CLASSES_ROOT\Microsoft.XMLDOM\CLSID
And inside that key is a REG_SZ value which contains the ClassID:
{2933BF90-7B36-11D2-B20E-00C04F983E60}
So basically the way it works is that COM is going to try to find the CLSID in the registry under the specified ProgID. I'm guessing it's not there or it's inaccessible somehow. If you want to figure it out for sure, crack open REGEDIT.EXE and take a look to see if the expected registry settings are there. If they aren't, there's your answer about why it's not working (for some reason the registration of the COM component isn't creating the ProgID keys).
If the settings are there, I would recommend running Process Monitor (sysinternals.com) and set up some registry filters to see what is happening when the registry is scanned for that ProgID.
Here's a little more info about ProgIDs:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd542719(v=vs.85).aspx