When talking about the Visual WebGui integration, we are actually talking about three different groups of integrations.

First part of the integration are the Integration tabs. You will find the Integration tabs in your project's properties, as can be seen in The new Visual WebGui integration to Visual Studio. Starting with Visual WebGui version 6.3, the integration tabs are only available in the Professional Studio.

The main purpose of the integration tabs, is to provide an easy interface to the various Web.Config settings that you might have to set specially for your Visual WebGui application. This is however just an inteface to settings you can set manually by editing web.config directly.

Second part of the integration are the project templates for the various types of Visual WebGui C# and VB.NET projects you can create. Starting with Visual WebGui version 6.3, the project templates are only available in the Professional Studio.

The Visual WebGui designer, provides a Windows Forms like GUI interface for editing of Forms and UserControls. Starting with Visual WebGui version 6.3, designer is available in Professional Studio and Express Studio, but not in the SDK version.

• The new Visual WebGui integration to Visual Studio
• Licensing

You can easily maintain your application settings without the Visual WebGui intgegration, by editing web.config by hand. Default web.config is created from the project templates, supplied with Professional Studio, and in case you do not have it, you can always grab a web.config file from another Visual WebGui application, and use it as a template. If all else fails, you can download the sources for the Catalog sample application and grap a web.config from there.

The default web.config file has comments that are usually enough to know how to change it. As an extra help, then you will find the corresponding web.config setting for every integration setting referenced in this section of this article.

Many sections in web.config are subject to inheritance. The inheritance chain starts at your server's machine.config and the inheritance chain goes on all the way to the web.config on your application's virtual folder. The inheritance chain is calculated from the construction of virtual folders and subfolders, not physical folder structure (see MSDN article - section Conflicts Between settings on Virtual and Physical directories).

The web.config inheritance is usually not a problem for normal Visual WebGui applications, but in some cases it is. As an example, take Visual WebGui application appA, which has a subfolder declared as a virtual folder where you deploy appB, another Visual WebGui application. The addresses for those applications would be http://mydomain/appA/Form1.wgx and http://myDomain/appA/appB/Form1.wgx. Normally, you would choose to have your "normal" web.config file in each of the virtual folders for appA and appB.

The problem with unchanged web.config files in this case is that appB will inherit many of the web.config sections included in appA and you will get configuration errors on many of them if you leave them unchanged.

There are two possible solutions to this problem. First, you can simply remove all the "duplicated" settings from appB's web.config and rely on they being inherited from appA. This will work for some sections, but not others. The other option is to add directives in appA's web.config to state that they only apply to appA, and should not be inherited to subfolders and thereby not inherited by appB on a virtual subfolder. For this, you use the <location> web.config tag.

The <location> tag is a wrapper you can use to wrap many (not all) of the web.config sections and thereby state where they should apply. In the case of preventing inheritance in our context here, you would wrap the relevant section of web.config in appA's web.config, and then leave appB's web.config unchanged. The syntax of the tag is

There is also a third option, which requires you to change appB's web.config. This method requires more work on your behalf, and if not executed correctly, will introduce further problems. If you view the web.config secions, you will notice that some are a simple flags that are set one way or the other. Other sections use <add...> to add settings and these are the sections that you get configuration errors for on appB, when it's adding keys that have already been added in appA.

All the sections that do support or use <add...>, they also support <clear ..> and <remove ...> tags. By starting all those sections in appB's web.config with <clear />, you will remove everything from that section before you start adding yours. This is not always safe to use, as some "keys" might be inherited from higher level than appA. It is therefore more safe to use <remove ...> on specific "keys", if you want to use this third method.

Using the <location ..> tag is the most convenient and least error phrone way of handling web.config inheritance issues.

In this section you will find most of the application settings that are directly relevant for your Visual WegGUI application. The settings are sectioned into groups where some are standard to Visual Studio without Visual WebGui being involved, but are relevant to your Visual WebGui application nontheless.

Adjusting the settings of your application in Express Studio or SDK version lacks the Visual WebGui integration and can only be set by manually editing web.config. For each integration setting mentioned in this article, the equivialent web.config setting will be shown, so it should be relatively easy to map between the two.

You should also take a look at the References section for forum discussions and links to further information.

• Web Settings
• Visual WebGui Integration settings
  • General tab
    • Keep Connected
    • Private Version
    • Authentication
    • Static Resources
    • Use Flash for Uploading
    • Inline Windows mode
    • Skins Preloading
    • Icons Preloading
    • Disable Obscuring
    • Show Debugger
    • Disable Caching
    • Enable Key Shortcuts
    • Forcing Domain and Port
    • Directories
  • Registration tab
    • Applications
    • Controls
    • Themes
  • Deployment tab
• Globalization and culture
• Other Web.Config settings

• Accessing configuration files programatically
• Custom HTTP handlers
• Visual WebGui Extensions in Deployment
• Understanding the web.config file

• Version 6.4 introduces setting metadata on per application basis
• Forum thread discussing metadata settings in 6.4

• Virtual subfolders and preventing web.config inheritance

• Visual WebGui will be able to run on medium trust in IIS in version 6.4 and later
• Running specific forms in SSL (HTTPS) while not others
• Running specific forms in stateless mode while not others
• Set culture of application based on culture in browser

• ASP.NET web.config settings on MSDN
• Web.Config inheritance
• Web.Config demystified