Jump to content


how do I copy a project to a web server?


  • Please log in to reply
6 replies to this topic

#1 Guest_Matt_*

Guest_Matt_*
  • Guests

Posted 19 January 2005 - 09:54 AM

Hi,

I am developing on a local machine with a SQL Server database. However, the database server is (and would be expected to be) different from the database server on my web server.

My question is: how do I copy a project to a web server which has a different database server to the saerver I built the project against?

I imagine most people would have this situation, developing against a database
different to the production instance, so I'm hoping it's simply a case of changing something in a config file after the project has been built locally.


Thanks,

Matt

#2 Guest_Paul_*

Guest_Paul_*
  • Guests

Posted 19 January 2005 - 10:04 AM

Matt,

TierDeveloper handles connection string differently depending on the type of components you have built. If you have generated .NET components for COM+, then you can go to "component services" and specify a different connection-string for the "activation-string" property of the components. By default, factory classes use hard coded connection strings to access database in case you donít specify it through COM+.

In case of NON GAC/NOT MTC components, TierDeveloper provides constructor in factory classes so that one can pass custom connection string. You can use project Config file (PROJ.dll.Config) to for this purpose.

Add the following lines of code in the default constructor of factory classes

For example

Public ProductFactory():base(ConfigurationSettings.AppSettings["Object.Product"] , TDevFramework.EDBProvider.OLEDB))
{
}

Now you can Built the components and then Application. The generated code will automatically read the connection information provided in the PROJ.dll.Config which is modifiable. You need to copy this file into the bin folder of your application.


I hope it helps clarify your thoughts. Please let me know if you have any questions.

#3 Guest_Matt_*

Guest_Matt_*
  • Guests

Posted 19 January 2005 - 10:06 AM

Thanks Paul,

I can't test this out unfortunately until the weekend but in the meantime can I just confirm:

Updating the appSettings keys in the PROJECTNAME.dll.config file for each of the objects is sufficient when migrating components to a different server.

Do I need to recompile after updating the config file?

I guess I should keep a local and a server config file, updating the server one manually whenever adding or removing components?

Sorry if this is answered below but I'm a little confused about whether I need to recompile or not; I would obviously prefer not to have to...

Thanks,
Matt

#4 Guest_Paul_*

Guest_Paul_*
  • Guests

Posted 19 January 2005 - 10:07 AM

Matt,

Actually, the generated code does not read connection information from Config file itself rather it uses the hard coded one by default. In order to customize the generate code you need to do a little work. After generating the code you need to write some code that should read the Config file for database connection information and then build the components.

Once the components are built with the modified code you will be able to modify this file without further building the components.

For example if you read connection information as ConfigurationSettings.AppSettings["Object.Product"] for the product object then it will always read the updated information from the Config file. Hence, this code will help you to move the components anywhere.

#5 Guest_Matt_*

Guest_Matt_*
  • Guests

Posted 19 January 2005 - 10:09 AM

Hi Paul,

The problem with this will be where you update objects regularly and for example test on a remote server. Every time I build a new set of components I need to update them with the config reading script as outlined below. If this only happens say once every few weeks then it wouldn't be a big deal but where development is ongoing and small change are released regularly it may be quite time consuming.

What would be ideal is if these settings were read in dynamically at run-time, in much the same way as you can do if building your own connections in VS.NET - by adding connection strings to the web.config file. Are there any particular reasons for Tier Developer working in the way it does?

If this is just the way it is then so be it - it'll just be an extra development process and I'll just have to release changes less often! I guess it will be less of a problem if I only build the components which have changed...

Thanks for your comments though; if possible I'd like to request this functionality for a future release, it would certainly make the process more straightforward when working in the way I describe above.

Thanks,
Matt

#6 Guest_Paul_*

Guest_Paul_*
  • Guests

Posted 19 January 2005 - 10:12 AM

Matt,

Thank you for your valuable feedback. I have forwarded your suggestions to engineering. We are planning to provide support for template customization in our next major release in which you will be able to handle this situation nicely.

Even now, one way to handle this situation is that you manually modify the template, that way you will be able to customize the connection string at code generation level. You don't then have to make changes in the generated code over and over. Here is how you can change the template.
  • Go to the folder "TierDeveloper .Net 4.0/Scripts/Components/C#/components" and open the file "ComponentFactory_cs"
  • Change the factory default constructor as given below, you may find it at line 70.

    public <%=CurrentDataobject.Name%>Factory() : base(ConfigurationSettings.AppSettings["Object.<%=CurrentDataobject.Name%>"], <%=libType%>)

    {

    }
  • Done! Now generate and build the components. After successfully generated the code, copy PROJ.dll.Config file to your applicationís bin folder.
  • Run the application and it will use connection string information mentioned in the Config file.


#7 Guest_Matt_*

Guest_Matt_*
  • Guests

Posted 19 January 2005 - 10:13 AM

That's fantastic - thanks!

I really appreciate your help with this, as I said I won't be able to test it until the weekend but it certainly looks good to me.

Thanks again!
Matt




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users