I am working with a vb.net Windows Forms application which has Application Settings, running under Windows XP.
The vs 2010 solution creates a MyApplication.exe.config but when I edit the file with notepad, the application ignores the changes even after reboot. Even if I delete the exe.config file the application still uses the settings from when it was compiled. So I decided to peek inside the exe file with a hex editor reveals the settings are encoded into the exe.
The user wide settings persist properly, but their default values are not coming from the exe.config but from elsewhere.
Is there something broken about my application or is this the way VB.Net Windows Forms Applications typically work?
Typically I develop console or service applications using C# where I can edit the exe.config without any problems.
The line in question:
If My.Settings.UseLocalOrGlobalSettingForOutputFolder.ToUpper.Equals("LOCAL") Then
The exe.config file looks pretty normal
<applicationSettings>
<DHModule.My.MySettings>
<setting name="UseLocalOrGlobalSettingForOutputFolder" serializeAs="String">
<value>Local</value>
</setting>
This is a visual studio 2010 solution with about 20 projects in it including a Setup Project. I have removed and rebuilt the project in question.
I have run out of time allowed for this project so.....
NOTE: I am going to work around this problem by not using any application-wide settings.
NOTE: I am going to work around this problem by not using any application-wide settings.
NOTE: I am going to work around this problem by not using any application-wide settings.
In app.config for the running executable look under <configuration> <configSections> <sectionGroup> and make sure the section exists: <section name="DHModule.My.MySettings"...
Related
I developed an application with VS2010 and a setup deployment with IS Limited Edition. The application provides some data in a XML file, which is installed in the same folder. If the app was making changes in the XML file, this was saved in virtualStore.
I use now VS2015 and Wix Toolset. The application can be compiled and I was able to code a WXS File. The new built MSI install the app and all seems ok. But now the app cannot access the XML file. The access is denied.
I tried to compare both MSI with Orca, but don't see something noticeable. I'm not sure, if this is a problem of setup or of the application itself.
edit
If I copy the "old" EXE file in the new installation, the application can access the XML file.
Thank you for help and hints
If a program appears to be from before Windows Vista, is running as a limited user, and attempts to write to certain machine-only locations, Windows may redirect its access to the virtual store as part of a backwards compatibility shim. If the program does not appear to be from before Windows Vista, no redirection is performed.
I believe Windows detects whether a program appears to be from before Windows Vista by reading its manifest for supported platforms - the supportedOS elements in the application manifest. My guess is the change in your toolchain from VS 2010 to VS 2015 has resulted in this element being added to your application's manifest (Windows XP is past its supported lifetime and thus Visual Studio 2015 can implicitly assume you are supporting at least Vista).
You may be able to override the manifest, but really you should fix your program to not attempt to write to per-machine locations. Ideally you should use a location such as the LocalAppData folder, although for backwards compatibility there may be benefits to at least reading the old file from the Virtual Store.
How can you publish a WinForm that uses a .dll extension into one .exe file? I'm using VB.NET on Visual Studio 2013.
I have tried several methods such as using only the program .exe file from both the Debug and Release folder but these didn't work in isolation - a runtime error happened every time a command from the extension was used, as if it didn't exist.
My problem is packaging the entire program into one file. I don't want to have to use ClickOnce applications because you can't use a custom logo and so it kinda looks bad. I'll use it if there's no alternative.
I realised that the answer was to use the setup.exe file when publishing. Also, changing the logo of a ClickOnce program is possible.
Basically what I need is the following. Depending of if I publish to production server or developpement server I want to use different databases. I've read a little on the topic and found out that I'm supposed to have a web.debug.config and a web.release.config And depending on which I choose from the dropdownlist in Visual Studio 2010 the appropriate web.config is being used.
The problem Is that I only have a Debug mode and a single web.config
If I add a release via the Configuration manager and call it Production I can only copy the configuration from Debug and cannot edit it.
I was usign this MSDN tutorial set it up: Tutorial
and at step 3 i noticed I didn't have the option necessary to change the configuration
Creating and Modifying Project Configurations
To create a project configuration
Open the Configuration Manager dialog box.
Select a project in the Project column.
3. In the Configuration drop-down list for that project, choose New.
I don't have the new option I can only use the debug option
My project Is actually a Website
In VB
I FOUND IT:
Since I am using a webforms Web Site, this option is simply not available.
VB.NET: Can the .EXE built by VS2005 be deployed as a standalone EXE?
When I change the mode in VS2005 to "Release" and build the solution, the bin\Release directory then contains the solution .EXE file, but also a .pdb, vshost.exe and .xml file. What are these extra files and are they necessary?
I copied the .exe file to another machine and it executed properly, but there was a significant delay when it first executed - thereafter it was like any other program. What is the reason for this, and can it be helped? Is it because the other 3 files in the Release folder are not there with it?
The project template that you used to get the project started doesn't have very optimum settings. You'll get the clutter as a result. It is easily fixable. Start with Project + Properties, Compile tab. Make sure the Release build is selected, upper left combo box labeled Configuration.
The .pdb file contains debugging symbols. You don't need it for the Release build although you get slightly more informative exception messages. The stack trace will contain line numbers. You cannot trust them for a Release build though. Click Advanced Compile Options, Generate debug info = None.
The .xml file contains IntelliSense info, it will be generated when you use XML Documentation in your source code. Meant to be used for assemblies that are referenced in another project, quite pointless for an EXE project. Turn off the "Generate XML documentation file" option on the Compile tab.
The .vshost.exe file is a helper process for debugging your app. It hosts a custom version of CLR, configured differently to help with security issues while debugging. It also makes the output of Console.WriteLine() appear in the Visual Studio Output window. There's little point in having it created for the Release build. Select the Debug tab and uncheck the "Enable the Visual Studio hosting process" option.
After making these changes and rebuilding, you should only have the .exe file left in the bin\Release folder.
The slow startup is what's called a "cold start" of the .NET framework assemblies. It is caused by a slow or fragmented hard drive. Since the DLLs were never loaded before, the disk drive needs to dig through the GAC to find the files. You can probably improve it by defragging the disk. Cold starts are never as fast as warm starts though.
A classic trick, used by Microsoft Office and Adobe Acrobat, is to warm up the file system cache by loading their DLLs at login time. They are called "optimizer" in the Startup folder or Run registry key. Very annoying btw, they slow down other programs. You can do the same thing by writing your own little .NET program that doesn't do anything but create a few classes. Put a shortcut to it in the Startup folder.
You should be able to just ship the EXE. The PDB and VSHOST files are used for debugging, you should be able to configure your Release build to not generate these files. You can set this in the 'Advanced Compiler Settings' dialog from the Compile tab in your project properties.
alt text http://philippursglove.com/stackoverflow/compilerdebugoptions.png
(Hat-tip to Amissisco for pointing out it's the same dialog in VS2005/2008.)
I'd imagine the 'significant delay' you experienced when running the program for the first time was due to the .NET Framework being loaded into memory (and probably then paged back out to disk) - unfortunately there's not much getting round that one. You could try throwing hardware at it - memory and a solid-state disk would probably give an appreciable speed increase but may not be a cost-effective option if your application is going to be released on a significant number of PCs. However this should only take place the first time you fire up the application after a machine restart, which is why subsequent launches of your application are quicker.
Only .Exe file is required for deployment. But its better to create a setup. If you are using App.Config file / Application settings, you need to copy the exename.config file too.
Yes, you can deploy it as a standalone EXE, together with any third party DLLs that do not belong to the .NET Framework as well as other resources such as application.config. images and/or other media assets.
The .pdb contains additional symbolic debug info which is not necessary for your application to run. It's meant to assist debugging so that you see your source code instead of assembly code in the debugger.
vshost.exe is used by Visual Studio only, not too sure about the exact purpose of it though.
Whether these three files (.pdb, vshost.exe and the .xml) are present with the .exe should not affect the loading speed of your application. As .NET applications have to be compiled upon first run, the delay that you're experiencing should be partially due to that.
We have a project management application written in VB.net. When running this application from a 32-bit machine or from within the Visual Studio IDE on a 64-bit machine, it looks for the correct configuration file (i.e. MyApp.exe.config). However, when running this app from outside the IDE on a 64-bit machine, it looks for MyApp.config and fails to find it.
Obviously I can copy the correct config to the badly named config, but we're at a loss as to why this behavior is occurring in the first place.
This is a windows application written in the 2.0 framework. No web.config file is associated (as I have found some references to a similar issue with web.config files that didn't apply).
Any guidance or suggestions is greatly appreciated.
Edit: I also should note that this is the only application this is occurring on. If I create a new vb.net application using the same libraries we use for config management, it works fine. Also, of some possible relevance, the projects are being built targeting the x86 CPU.
What I'd do is on 64 bit at install time I'd do CreateHardLink("MyApp.exe.config", "MyApp.config", NULL)
CreateHardLink is P/Invokable.