I have several projects in a .NET Solution, and I want to decentralize all the configuration for all the different environments of the app to a "Web.Environment.Config" (Web.Dev.Config, Web.Pre.Config, etc...)
The problem is that one of the projects, a Class Library called Services, is the responsible of database and WS connections, and seems that the config could not be decentralized (or I do not know how to).
This is the "config tree" of the Solution:
- Solution
|-- Services (Class Library)
|-- app.config
|-- WebService (WebServices project to expose some services)
|-- Web.Debug.config
|-- Web.Dev.config
|-- Web.Pre.config
|-- Web (Web Application)
|-- Web.Debug.config
|-- Web.Dev.config
|-- Web.Pre.config
As all the database connections is realized inside the Services project, I can not decentralize the config.
My objective is to have all the configuration in just one config file by environment (in all the Solution). Is it possible?
Related
It's possible to share same bin folder for different web application (.net 4.6) on Azure App service (it is possible also on IIS)
I'd like to have on bin folder, and for each web application have different web.config like showed below
root
|
| BIN (share *.dll)
|
|- App1
|-- web.config
|
|- App2
|-- web.config
|
|- App3
|-- web.config
Thanks!
I have installed symfony 4 on my shared hosting.
My structure is like this:
ROOT
|
|-- public_html
|
|-- tst
|-- tst
|
|-- bin
|-- config
|-- src
|-- translations
|-- var
|-- vendor
|-- composer.json
|-- composer.lock
|-- binsymfony.lock
I moved index.php from the public folder to the public_html/tst folder and changed the paths inside that file to match the new structure:
require __DIR__.'/../../tst/vendor/autoload.php';
Now, when running http://mysite/tst, I get the homepage of the site as expected. But when I try another route (other than "/"), I always receive a 404 page not found.
Does this have something to do with privileges of am I missing something?
I figured this one out myself, but if someone tell me how to deploy a Symfony 4 application to a shared hosting, please tell me! I think other people will like this too...
You can create symlik for Public. The method you try can lead to problems.
# Enter Directory Root
cd /root_dir
# Create Symlink
ln -s public_html tst/public
Serverspec is used to check on several servers. Therefore the recommend structure of roles is used:
|-- Rakefile
|-- spec
|-- app
| -- ruby_spec.rb
|-- base
| -- users_and_groups_spec.rb
|-- db
| -- mysql_spec.rb
|-- proxy
| -- nginx_spec.rb
|-- spec_helper.rb
To read the data and structure I use a yaml-file.
On the serverspec website is in the Rakefile inside the Raketask the following:
ENV['TARGET_HOST'] = host
Why should I set the host as an environment variable? Wouldn't a local one be enough?
The default spec helper uses it to target hosts for the net-ssh gem. You can refactor the host targeting code in the spec_helper to not even use it if you want and then just use host_inventory for the hostname.
Note the following:
https://github.com/mizzy/serverspec/blob/master/lib/serverspec/setup.rb#L276
https://github.com/mizzy/serverspec/blob/master/lib/serverspec/setup.rb#L292
Despite the anonymous downvote, this is absolutely the correct answer.
I have different webapps that share a large portion of the web.xml configuration. For example, the way some servlets are mapped is identical for all apps, but some webapps have custom servlets, or an additional filter, or shared managed beans.
Each webapp is a different project in my IDE. I would like to refactor the common part of my web.xml to a "common" project, and let all the application-specific web.xml's extend the "common" web.xml. Is there any possibility to do this?
Yes, you can. Assuming Eclipse (your question history confirms that you're using it), just create a "Web Fragment Project":
And associate it with the main project in the wizard:
You can if necessary (re)configure it in "Deployment Assembly" property of the main web project (or any other way of configuring the build in such way that it ultimately ends up as JAR in /WEB-INF/lib of main web project).
It's basically a Java project with the following folder structure:
CommonWebProject
|-- com.example... (you can put e.g. #WebServlet classes here)
|
|-- META-INF
| |-- resources (you can put shared web resources here)
| | |-- common.css
| | |-- common.js
| | |-- template.jsp
| | :
| |
| |-- beans.xml
| |-- web-fragment.xml
| `-- MANIFEST.MF
:
Any content in /META-INF/resources folder is resolved the same way as webcontent of the WAR (my Eclipse Luna SR1 didn't precreate the /resources folder, so you'd need to manually create it). And, importantingly, any resources (including classes!) with the same name already in the WAR will have loading precedence over those in JAR, so you could if necessary "override" a common JAR resource from WAR on that way.
Note that the web-fragment.xml file must be named exactly like that and thus not web.xml. The IDE should just autogenerate one for you, but for sake of completeness, a Servlet 3.0 compatible one look like this:
<?xml version="1.0" encoding="utf-8"?>
<web-fragment
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"
version="3.0"
>
<!-- Put shared web.xml config here. -->
</web-fragment>
See also:
Structure for multiple JSF projects with shared code (in case you're using JSF)
If you deploy your apps on glassfish, than you can put your common configuration in default-web.xml file under the domain-dir\config\ location.
Usually web servers have feature to define default web.xml which caters to your requirement. I would suggest to explore that option for the web server you are using.
My team is currently working on an ASP .NET website. We are one of the first teams in our organization to use TFS2008 for source control. When I joined the project, it had already been active for a few months. Below is a diagram of the basic file structure we are using in TFS:
$/TfsProject/
|
| /* Contains our in-house class libraries. */
|-- Common/
| |
| |-- Extensions/
| | |-- Extensions.csproj
| |
| |-- Loggers/
| |-- Loggers.csproj
|
| /* Contains third-party libraries. */
|-- Library/
| |
| |-- EnterpriseLibrary/
| |
| |-- v4.1/
| |-- Microsoft.Practices.EnterpriseLibrary.Common.dll
|
| /* Contains the website itself. */
|-- Site/
|
|-- Packages/
| |-- Packages.csproj
|
|-- Website.root/
|
|-- Website/
|-- Website.sln
|
|-- Website/
| |-- Website.csproj
| |-- Default.aspx
|
|-- WebsiteUnitTests/
| |-- WebsiteUnitTests.csproj
|
|-- WebsiteWebControls/
| |-- WebsiteWebControls.csproj
|
|-- Utilities/
|-- Utilities.csproj
The main website solution (Website.sln) currently contains fifteen projects (including each of the .csproj files displayed in the diagram). Yesterday a decision was made that the projects contained in the Common directory should be moved into their own solution, and we should include them in the Website by referencing the compiled DLLs instead of the projects themselves. Anytime one of the Common projects is updated, all other projects that use it should begin using the latest version with minimal effort.
Is there any easy way to implement this, based on our current hierarchy? I have read the TFS patterns & practices guide, but implementing any its suggestions would require significant changes (as well as updating all of our projects and solutions). Also, our organization is waiting until TFS2010 is released before they enable Team Builds -- so they're unavailable to us.
The more "portable" solution would be to have a build specifically for the shared projects/solutions. The last step of those builds is to check in the binaries into a publishing folder (possibly under /libraries). When getting latest for the client projects (those referencing the binaries) you will end up pulling down the latest binaries. You don't lose the ability to branch the client projects and team members are free to map folders as they choose.
I will say as a whole, you should reconsider your folder structure. It doesn't allow for a very flexible branching structure. You appear to be using your TFS repository much like many VSS users historically have: As a versioned file system.
A solution that may work is to have
the projects in Common all output to
the same directory ("C:\temp\dlls"),
rather than each local /bin folder.
That directory can then be added to
the Web Project solution. All of the
references to the DLLS should be made
to the common folder pulled from TFS.
That directory can be added to TFS as
a folder. Everyone on the team will
have to have the folder mapped
locally with the same relative path
to the solution file.
The place where the "minimal effort"
piece breaks down is that the files
will have to be checked in/out when
compiled. The rest of the team would
then have to GetLatest. The GetLatest
requirement may actually be better,
because you don't want changes forced
to you while you are in the middle of
developing.
You basically end up having a folder with compiled dlls added to the web project solution. That is also the same folder that all the Common dlls are built to. That folder is where all the projects in the web solution reference the Common Dlls. When someon rebuilds, they have to check out the dlls in the folder, build and then check back in. When a developer wants the latest, they call GetLatest on the folder and rebuild their projects.
This actually worked for us in a similiar situation where we had compiled dlls to reference. The difference for us is that the compiled dlls chagned so infrequently, that the whole "GetLatest" paradigm never came into play.