I have two different applications deployed on common shared hosting (using hostgator services).
One application is deployed on root folder and another one is deployed in sub-folder created on root. But the application deployed in sub-folder is not using web.config file available in sub-folder, it is using same web.config available on root folder.
Please help me to find out way how to use different web.config files for all different sub-folders on shared hosting.
The only way to have a subdirectory act as a separate application with its own web.config is to configure it to be a separate IIS application.
In a dedicated hosting environment, you'd do this within IIS. However, the fact that you're on a shared hosting platform doesn't automatically make it impossible. Most shared hosting provides a web interface that you use to configure your site, and often - but not always - that interface will give you the ability to set up subfolders as separate applications.
I can't tell you whether you have this option or where it is, since I don't know what control-panel software/product your hosting uses (and even if I did, I probably wouldn't be familiar with that specific product/version, but it's worth having a dig around in your control panel to see if you can find it somewhere. If not, try contacting support - they might be able to point you in the right direction, they might offer to do it for you in IIS, or worst-case scenario is that they'll tell you they don't offer that service (at least then you'll know, and can start looking elsewhere for a new host).
Unfortunately, there's no other way to do this - you can't for example add a setting to the root web.config to tell it to treat a subfolder as a separate application, because applications exist at the IIS level not the ASP.NET level.
In general, the code in the subfolder should be using the web.config in the root folder, plus the web.config in the subfolder. Exactly which settings are not being used in the subfolder?
It is not necessary to have the subfolder be an application just in order to get the two config files to merge. It is necessary if you want the sub web.config file to be independent.
Related
I have the basic blazor project that im trying to host in a specific way. I have managed to host the app in IIS where all the files were in the same folder. The issue im having is the web config in the root folder and then having the actual app itself in a subfolder.
IIS app file structure
im using blazor server which is sitting the "test" folder.
test folder where the blazor app is, seperate to the web config
Is this even possible to host in this way? or is there routing or config that needs to be done to get it to work?
Thanks,
So far I'm afraid it is unavailable to host application in site level. No matter I set the aspnet core handler in root level or folder level, change location value,change processPath. IIS just ignore the attribute even I have set it in both root level and folder level.
I think even you were able to host blazor in a sub-folder, Duplicate attribute verification is easy to crash the application when you need to publish something in root folder.
So the best way to handle this is convert test folder to an application. Then everything get isolated and start working.
interesting idea
I see no reason, why not to create a sub directory as website in iis. There have to be a extra app pool unmanaged for each.
Now I have seen this question before on SO in a variant ways, but surprisingly not in this form:
I have a solution with multiple web services (projects) that need to talk to each other. After publishing each of these web services might end up on a different machine with a different database. To tell each web service where all other web services are, I want to maintain a single config file during development.
I would like to expect that after publishing the config to be present in each published project. And I would like to expect the config file to be editable after publishing, so I can swiftly migrate a certain web service and then just edit all config files of the other web services.
I don't want to do this in the database, for the config file its self should also hold connection settings to the database(s).
I came across the following ideas/thoughts/questions:
I have a dll project called 'common' that is referenced by other projects. Let's give that one a shared.config and build a class in that project that can be used to read out the shared.config by doing System.Configuration.ConfigurationManager.OpenExeConfiguration("shared.config"). Just need to make sure the shared.config will be published along with the DLL.
I would favor this solution, as it would also let me keep a web.config inside each project having just the project specific settings. And have the shared.config having the shared settings. But I read on SO that this should not be considered lightly and could have some unwanted side-effects, like file-access-issues; though I wonder if this would apply to my case. Also I would like to ask your help here on how to actually realize this as I don't think Visual Studio supports app.config for DLL projects out of the box.
I also thought about creating a shared.config file in the Solution Items. Then linking that file inside each project. And in the Web.config of each projects, add: <appSettings configSource="shared.config" /> pointing to the linked file in that project.
Though I cannot find any reason why not to do this, first implementation failed. It seems (at least during development), c# cannot find the linked shared.config file. I'm guessing linking files is not done instantly nor maintained after creating the linked file, but the file is only copied to the projects WHEN I do a publish. Thus leaving the file missing during development. Is this correct?
The config files are app specific. This mean that you can add a config file to a class library but the file will then by used by the app (windows service, webservice and so on) referencing the library.
Same thing for external configSource, this are app specific as well and need to be included withing the project using it.
So if your solution is composed by 2 projects you then need 2 config files. One for each project.
While for a windows based application(services, winforms) the expected folder for config files is the bin directory, for web based projects this will be the directory is the root folder of the virtual directory.
This said, using a shared config file looks the easier solution (and you don't have to copy the app.config from the class library for each project). Here are the steps :
Create a solution folder.
Add the config file to it.
Add the file as a reference for each project needing it. Right click the project and Add existing item - > Choose the file and Add as link
Ensure the file is always copied by setting the copy option (properties of the file) with Copy Always.
At this point you should have the config file deployed into your project directory everytime you compile the solution.
EDIT:
I'd avoid looking into the bin for config files within a web app, the
convention is that file should be in the root, so I would avoid the
first option.
Linked files end up in the bin after building the project. Try the same steps for importing the file but this time simply add it (not as link) and it will be deployed as content in the root of your site, so it can be always available.
If your hosting in IIS it is possible to have a single web.config file at the root site level but Giorgio is right in that app.config files are app specific. it is possible to use custom build steps to automate the copying of config files across multiple projects so personally I would go with that.
This actually drove me a bit crazy. In the end I fixed it like this:
Created a Shared.config file in the dll project 'common', having the contents look like any ordinary web.config/app.config.
Set the file to be Content and Copy Always, so it would surely be copied out to all projects that reference project common. (Though the config file will indeed end up in the bin folder.
Created the class SharedConfiguration inside the common project. The really tricky part was having to use OpenMappedExeConfiguration() , and getting the path to the executable directory (including bin, and without file:// in front of it).
Now when I want to access a setting from the shared settings, I do SharedConfiguration.instance.AppSettings.Settings["CubilisEntryPointUrl"].Value.
(I cannot use SharedConfiguration.instance.AppSettings["CubilisEntryPointUrl"] directly because of this issue)
.
public static class SharedConfiguration
{
public static readonly Configuration instance = GetConfiguration("Shared.config");
private static Configuration GetConfiguration(string configFileName)
{
ExeConfigurationFileMap exeConfigurationFileMap = new ExeConfigurationFileMap();
Uri uri = new Uri(Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase));
exeConfigurationFileMap.ExeConfigFilename = Path.Combine(uri.LocalPath, configFileName);
return ConfigurationManager.OpenMappedExeConfiguration(exeConfigurationFileMap, ConfigurationUserLevel.None);
}
}
I want to know for sure if there are any possible issues for not publishing an ASP.NET solution.
In my company current policy (strangely) they just copy the web project dll, and needed references dlls, web.config and global.ASAX and image files over the existing ones on the IIS web server(Virtual Directory is created).
Do you see any issue with the above?
Your feedback is greatly appreciated.
Don't really see a problem with this. It's sort of what we do. We publish to a folder - any folder, check the web.config against live, then zip it up. We then create a change request, referencing the zip file & pass this to the hosting team to deploy.
This works great for us, but then everyone has different views & circumstances. I don't really see it as a technical issue, but more of business process issue.
It used to be that you copying files was not good enough, because you needed to create a virtual directory/Application within the IIS configuration system for your applications. Recent versions of IIS allow you to handle this entirely within the app.config, and so it's much less of an issue.
I'm having a "tiny" issue with my App_Code folders.
I'm learning ASP.NET and, therefore, ordered a webserver with the support of ASP.NET 4.0. I'm using Visual Web Developer to program my webpages. When I upload my website to this webserver everything runs fine.
However, if I then add another web project to my server, my App_Code folder gets all messy. The server wants all my class files in the App_Code folder in the root. Is there any way I can create subdirectories in my App_Code folder or something to keep my projects organized or am I missing the point here?
You should take a look at codeSubDirectories in the web.config
Alright I found a solution to my problem. Although most of your answers might work aswell, this proved to be the best in my case. I created a subdomain and threw all files into that folder and it worked fine.
You should try to avoid using the App_Code folder for your own stuff, especially if you're using a web application project.
Whenever you convert a website to a web application project, the process actually renames your existing App_Code directory to Old_App_Code.
See Here, even though this is specific to converting .net 2.0 apps, I believe it still holds true in 4.0 since converting a 4.0 app does the same thing.:
VERY, VERY IMPORTANT: Because ASP.NET 2.0 tries to dynamically compile any classes it finds under the /App_Code directory of an application at runtime, you explictly DO NOT want to store classes that you compile as part of your VS 2005 Web Application Project under an "app_code" folder. If you do this, then the class will get compiled twice -- once as part of the VS 2005 Web Application Project assembly, and then again at runtime by ASP.NET. The result will most likely be a "could not load type" runtime exception -- caused because you have duplicate type names in your application. Instead, you should store your class files in any other directory of your project other than one named "app_code". This will be handled automatically by the "Convert to Web Applicaiton" command. This command will rename the folder Old_App_Code.
If you have access to a hosting control panel it's probably best to configure your hosting environment with a virtual folder for your second website and run it from the sub folder, e.g. www.example.com/project-b. The first site can still be running in the root folder, e.g. www.example.com.
So both sites will essentially be isolated from each other (just like they are now isolated as two separate projects in Visual Web Developer Express). And both sites have their own App_Code folder (and web.config file).
If you don't have access to a configuration panel, most hosting providers are willing to add a virtual folder for you, since it's really not a special requirement.
The virtual folder should show up as a regular folder in your FTP folder, usually inside the www or wwwroot folder. Now you can copy your project files into that folder.
Take care to use root-relative paths for URLs in your second project, so all links will work even when the website is run from the subfolder. Root-relative URLs look like this:
<asp:HyperLink runat="server" NavigateUrl="~/Default.aspx" />
<asp:Image runat="server" NavigateUrl="~/images/logo.png" />
This will automatically go to www.example.com/project-b/Default.aspx and www.example.com/project-b/images/logo.png when the website is deployed in the virtual folder.
If you need to re-use code from one site in the other, it's typically best to move such code into a separate Class Library project type, and then add a reference to that project to each website project (right-click the website project, choose Add reference..., then select the Projects tab and select the Class Library project).
While using a third party dll I was getting the following exception:
exePath must be specified when not running inside a stand alone exe
with the following trace
System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath).
The reason I found was that it was looking for app.config and I had provided the details in web.config. My question is: why does the system.configuration differentiate between web.config and app.config? Any thoughts?
Executables:
Several .NET executables can live in the same directory. As there cannot be two files with the same name in the same directory, the applications must use different names for their main configuration files. The applicationName.exe.config scheme solves this.
Web applications / sites:
.NET web applications are compiled to DLLs, and web sites are usually compiled just-in-time. Hence, there is no "main entry point" in these types of projects. It is possible to create a web project where each page is compiled to its own assembly. Which one is the main assembly? Which assembly should we name the configuration file after?
Fortunately, only one web project can be hosted from a single directory, so only one main configuration file is going to live here. This allows for the main configuration file name to be picked by convention, and that file name happens to be web.config.
web.config is for your website and web applications only. It stays fixed, i.e. doesn't change its name; it's always called web.config.
app.config is for non-web applications - Winforms, WPF, NT Services etc. This will be renamed into YourApplicationName.exe.config when you build your project. You won't ever find an app.config by that name in an application's directory (or if you do, it will not be used).
Why Microsoft choose to use two different kind of names - I don't know - ask Microsoft.
So you basically just have to know what you're dealing with and provide the information in the correct place.