I have a server, lets say www.myserver.com and i want to host a php symfony application for several customers.
For example customer 'abc' and 'xyz' I will have 2 separated database abc and xyz
Now, I want my customers to access like this:
www.myserver.com/abc
www.myserver.com/xyz
I'm a newbie at Symfony, my application works when calling www.myserver.com/abc/app_dev.php its in development
I have routing problems for the home page, and I dont see how to specify the database, because the parameters.yml files seems to be shared
Thanks for hints
Regards
Had the similar issue some time ago. What I had to do is to have:
/client_1 (Client1 app dir)
/client_2 (Client2 app dir)
...
/web
/client_1 (Client1 web dir)
/client_2 (Client2 app dir)
...
This way, your have separate apps which share the same codebase (src) but also have separate logs, config, etc...
But please, reconsider the decision to have this. I learned too late that I should not have done that way. By that time, it was too late to do anything. The reason was that some of the clients requested "special" features which other did not.
Hope this helps...
Related
I don't think there is an answer to this one but I'm often wrong, so fingers-crossed I am this time too.
(1) In Visual Studio 2019 I have one Solution consisting of two Projects, both WebForms.
(2.1) Project1 stores book information (but that's not really relevant).
(2.2) Project2 logs to a database any exceptions caused by Project1. It has a single logFilter.aspx page, used to view those exceptions.
(3) I've added a reference to Project2 in Project1 but this isn't about sharing code, so that's not really an issue either.
(4) My question is, when I navigate to Project1 in a browser, is there any way I can access the logFilter.aspx page in Project2?
(5) Right now for example, I have to change the Solution's Properties to make both Projects "startup projects". Then I can access them both separately - in separate browser windows - like so:
(5.1) https://localhost:44340/bookPage.aspx (Project1)
(5.2) https://localhost:44389/logFilter.aspx (Project2)
(6) That works fine on my local machine during development. But I really don't see how it could work once I've deployed the lot to my web hosting company's IIS (at www.Project1.com for example) on the Internet.
(7) I could add the logFilter.aspx page to Project1. But then I would have different versions of it dotted around all my future projects.
(8) I've searched Microsoft Docs and StackOverflow but the few answers I've found seem to be MVC-related. This post does seems to provide an answer by adding a key to web.config like so:
<add key="WebsiteURL" value="http://localhost:2030/" />
and then using:
Response.Redirect(ConfigurationManager.AppSettings["WebsiteURL"] + "SRF-GeneralInfo.aspx");
I'm no expert but I'm assuming that I wouldn't have that Port information once I'd deployed it to a web hosting company's web server on the Internet.
The answer here suggests that you either make one project the child of another or that you use virtual folders on IIS which I doubt I would have access to.
Strange, as I would have thought this would have been quite a common practice for developers to want to do. Still, any thoughts anyone has would be most welcome.
Thanks in advance,
a setup that might work better is that you have a solution with two projects. Project1 is the webapp BUT PROJECT2 is a library.
Now when you get an exception on project1 you can call the class/function what you might need in project2 and log the information.
future projects (3,4,...etc) can still reference project2 for logging purposes.
I would like to have a return on your experience concerning Symfony 2 projects :
Has anyone experience putting all of the projects inside the same enveloppe (each project is a bundle for example). why is it bad ?
Another solution : put the vendor folder somewhere on the server and point to it in all Symfony 2 projects (that means there is no vendor folder in the projects). What do you think about that ?
Thank you
Answer 1
It is bad because you will have a single config for each project, so a single database user etc. Not to mention best practises. There is nothing stopping you doing this, but it has bad news written all over it.
Answer 2
If you put the vendor folder somewhere else on the server you will not be able to have different versions of external libraries per project, which is actually important.
If you have common services that more than one project use then I would consider setting up APIs for each services so other projects can access it. OR you could import that bundle.
I made a simple REST API bundle with Symfony 2 and now i want to use ember.js as a client.
I made a new bundle for it (ClientBundle). Where should i put the js files? Into
the ClientBundle/Resources folder under public/js?
app/web under public folder
somewhere else
what is the best practice / your favourite folder structure?
The best practice is to put the client code into a separate repository and use JS specific tools for its development.
Just because you can put them into a single repository doesn't mean you should. Imagine what a mess that repository will become if/when you add other clients like Android, iOS, and so on.
We put the client JS under Bundle/Resources/public/ and have a separate frontend and backend bundle. We just published a sample distro to show how this is organized here:
https://github.com/ucsf-ckm/symfony-emberjs-edition
Currently the answer would be to store the assets in the /web directory. Source
If you intend the ClientBundle to be reusable across different projects you may have, you are best served by placing the files into the ClientBundle\Resources\public\js folder.
We are hosting huge app for our cutomers. There are diffrent configuration and contents (images, user files). But the core code, directories structure, databse scheme is this same for every client.
I'm looking for a way to create one core code repository, so all clientes will use it. We do updates often, so this will make our live easyer.
The idea is to create the repo and In clients directories create just symbolic links to that repo direcories: bin, App_Resources, Css, SystemImages etc.
Is this a good idea? Will ASP.NET MVC app handle this correctly, or I've to add some code for it handle the 'virtual direcotories'?
I would suggest that you take a look Single-tenant and Multi-tenant applications even if you say that your code base is the same for every one.
Here is a nice Multi-Tenancy ASP.NET example
I would also suggest that you check http://appHarbour.com as you can easily push changes from your master repository to appHarbour using Git or Mercurial.
Regarding your exact question, I also keep static files in a custom scheme under Amazon S3, so each client can upload there own files, plus the ones I have and all is based on a single location that does not put more resources just to delivery static files.
You can see my live web application using this technique checking the View Source.
How can one specify the connection string in a config file of a class library and later modify this when used in a ASP.NET Web Application?
The Class library is a data access layer that has a Dataset connecting to a database based on a connection string specified in a config file (Settings.settings/app.config).
This class library is used in a web application where user inputs data and is written to the database using the DAL classes & methods exposed in the class library.
Now, I want to migrate this application from development environment to testing environment and later to production. The problem I'm facing is that after migrating to testing, the app in testing still connects to development database. I've changed the connection string mentioned in <class library>.dll.config file but this seems to have no impact.
Can someone explain the right way to achieve this? Thanks in advance for any help. Cheers.
With the .config files the name has to match the main executing assembly. For example I had a situation like yours, I needed a class library to have its settings in a .dll.config file. While it was able to reference it the actual application would not be able to read the config file because it was expecting .exe.config. Renaming the .dll.config to .exe.config fixed the problem.
In your case migrating your connection strings from .dll.config to web.config should fix your problem!
Good luck!
Joshua is partly right ... For posterity I would like to add a bit more to this answer as I have delt with the same problems on several occasions. First, one must consider their architecture. There are several issues you can run into with .config files in ASP.NET based on deployments.
Considering the architectural ramifications:
Single tier (one server):
A simple web application may be able to leverage a reference to the sites Web.config file and resolve your issues. This would be a fine solution for a single tier application. In the case of a windows application leveraged as a .exe file, the App.config will work too.
Multi-tier (more than one server):
Here is where things became a bit hairy for me the first time I was working with .config files across boundries. Remember the hierarchy of the config structure and keep this in mind (MSDN Article on .Config structure) - there is a machine.config at the root in the appropriate ASP.NET folder. These reside at each physical server. These are overridden by the site Web.config (or App.config) which are in turn overridden by subfolder .config files. If you have more than one .config file you may want to use one of the methods to pass the file path for the specific .config you want to use. More importantly, these files each may have connection information. ASP.NET's machine.config holds some for the framework ... so you should at least be senstive to the fact this is an "inheritance" chain. Second, any changes to the Web.config file once deployed will tell the application to restart. This will result in loss of state (bad if you have active users on the site). The way around this is to keep a separate .config file (e.g. connections.config) and put a reference to that file in the Web.config. This will allow you to change the connection information (e.g. password) without having to restart the application. Here is a link to more info: MSDN: Working with Configuration Files. This article lays out all the details you need to be aware of in a normal server / IIS deployed application. Keep in mind that the .config files are mainly intended for applications, not libraries. If you have several tiers, chances are you are using some communicaiton / messaging layer (e.g. WCF). This will have / allow its own Web.config. You can keep connection strings there (and encrypt them if needed), but better yet, put them in a second file referenced by the Web.config for manageability. One final point, if you are ever going to consider the cloud, .config files are wrapped for application deployments which in effect removes all of the benefits they offer in terms of "not having restart or redeploy". Azure deployments will want to consider this article to save themselves from nightmares of maintenance: Bill Lodin blog - Configuration files in Azul / Cloud. One other point on this article – great example on how to programmatically select configuration depending on deployment! Be sure to check that out if you want to add flexibility to deploy in or out of the cloud .
I hope these points saves all of you time and headaches. I know I lost a couple days of programming time dealing with these issues ... and it was hard to find all the reasons in one place why may app was not "implementing" its connection object. Hopefully this will save you all from the same fate I had.