Asp .Net Config Path Options

bigbadcon

Hi folks,


Looking for a bit of advice from any asp.net gurus...

I have a few sites that are all 90% similar and i'm trying to minimise the time it takes to merge / check changes across the code whenever I make a change to one site.


One of the main things that would help would be if I could put the absolute path of the site in a config file so I wouldn't have to view these changes in the compare tool I use.

Eg.

Instead of

www.mysite.com/mypage.aspx

I would use

<% MyWebConfigValue %> & "/mypage.aspx"

My question is...

What is the best way of doing this?
Will this server side check kill my page loading time because of all of the server side calls for every link?

Also... Would it be better to just use Relative links instead of absolute? I have heard it is better for SEO using Absolute links which is why I am using them at the moment.

Any advice would be appreciated.

fatlog

hi,

not sure of the answer to your question!
but from reading your description it sounds like you have a different issue which you should look at resolving. I could be wrong on this but from what you've mentioned it sounds like you are duplicating a lot of code. i.e. you have a number of sites, each with similar code and when you make changes in one you then have to make the corresponding change in each site.

if this is the case you should really refactor the sites and extract the dupliacted code out into a type of core module which each of your sites uses. Then you only need to make the changes in one place. Nice and DRY - 'http://en.wikipedia.org/wiki/Don't_repeat_yourself'.

If I picked you up wrong then sorry about wasting your time!

bigbadcon

Hi fatlog,

Your probably right about using a core module which i have been meaning to do.

This would stop the hassle of merging the code behind files but to be honest that isn't really the part that's taking me a long time its more the aspx files.

Most of the time when im merging changes the code behind files are very similar and its easy to do but comparing aspx files can be hard work.

Thats why im thinking if I can get rid of the URL differences it might be easier to do.

I'm starting to wonder if I should just have one main application with different configuration files for each different site with the exception of some pages that have custom links that are different from site to site...

Maybe I could override these pages??

fatlog

ASP is not really my thing but it sounds like you just need to setup some defines for each site. Each site for example would have its own settings page which has a define that holds its URL.
you just override the settings for each site.

are you using any frameworks? there might be a solution in it if you are

mewso

Are you aware of the ~ in .net. i.e? "~/mypage.aspx will default to the root of the current site. Using this in every site would mean all files could be the same. Of course it will only work in asp.net controls like a hyperlink's navigateurl property or in the <% %>.

bigbadcon

Hi mewso,

Yeah I used to use that but changed to absolute URLs because I heard that they are better for SEO.

Also the majority of the links on the pages are not ASP hyperlinks.

The <% %> tags are where im thinking of using the configuration value for the standard links.

Im gonna try and get the "SiteName" from the web config in the Application_Start method in the Global.asax

Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
        ' Code that runs on application startup
        CommonCode.SiteName = CommonCode.GetConfigFileValue("SiteName")
    End Sub

Then when I have this i'm thinking of using it in each link as follows:

<a href="<%=CommonCode.SiteName%>/MyPage.aspx">My Page</a>

I think this way will work fine but im wondering if it is bad practice and there is a better way to do it?

Maybe using the ~ will solve the issue alright but wouldn't like it to affect SEO.

mewso

There is a utility class with this method VirtualPathUtility.ToAbsolute but it doesn't appear to do what you want. There should be some utility that would do it for you.

As far as the web.config goes the built in settings class is the way to go I think. It will compile your settings into strongly typed properties. Right-click on your project and select properties and edit the settings tab to add your settings so they will be compiled. I would imagine this would have little or no hit. Once created they can be changed in the web.config at any time.

*edit in vb.net you access a property like this My.Settings.MyProperty. Very slick. The method in c# escapes at the moment.

bigbadcon

mewso wrote: »

As far as the web.config goes the built in settings class is the way to go I think. It will compile your settings into strongly typed properties. Right-click on your project and select properties and edit the settings tab to add your settings so they will be compiled. I would imagine this would have little or no hit. Once created they can be changed in the web.config at any time.

I have always just used the following format in the web.config

<appSettings>

<add key="Something" value="SomeValue"/>
</appSettings>

Didnt know it would compile it doing it the other way. Cheers , I'l give that a shot

bigbadcon

mewso wrote: »

As far as the web.config goes the built in settings class is the way to go I think. It will compile your settings into strongly typed properties. Right-click on your project and select properties and edit the settings tab to add your settings so they will be compiled. I would imagine this would have little or no hit. Once created they can be changed in the web.config at any time.

*edit in vb.net you access a property like this My.Settings.MyProperty. Very slick. The method in c# escapes at the moment.

Having trouble figuring out how to do this.. I don't have a settings tab when I look at the solution properties.

I can add a resource file though, is that what you mean? I added one but nothing looked accessible from the web config?

Malice

bigbadcon wrote: »

Having trouble figuring out how to do this.. I don't have a settings tab when I look at the solution properties.

I can add a resource file though, is that what you mean? I added one but nothing looked accessible from the web config?

I assume mewso means this (It's VS2010, don't have earlier versions installed on this box):



Note that this is the project settings, not the solution settings.

mewso

Thats the one.

bigbadcon

Malice wrote: »

I assume mewso means this (It's VS2010, don't have earlier versions installed on this box):

Note that this is the project settings, not the solution settings.

I know now why I couldnt find the setting.. Im using Visual Studio 2005 which changed the way web applications are structured, they dont have project files just solution ones :eek:

Malice

bigbadcon wrote: »

I know now why I couldnt find the setting.. Im using Visual Studio 2005 which changed the way web applications are structured, they dont have project files just solution ones :eek:

Yes it does. Here's a screenshot looking at the same thing in VS2005. Again, it's project settings rather than solution settings:



The above is a solution consisting of one web application and nine class libraries in a mixture of C# and VB.NET. What way have you got your solution set up?

mewso

There may be a setting in options that hides the solution node.

bigbadcon

Think i've figured this out....

If you go into Visual Studio 2005 and choose...

File -> New Website

You get what I have which is just a solution file with no project.



If you choose ..

File -> New Project -> ASP.Net Web application

You get a project file and a solution file.

Bit confused about the difference to be honest....

mewso

A website is a non-compiled web project and the .vb/.cs files have to be deployed with the app wheras a web application is a compiled app with a .dll in the bin folder and .vb/.cs files do not need to be deployed. There are many advantages to sticking with web applications over websites.

bigbadcon

mewso wrote: »

A website is a non-compiled web project and the .vb/.cs files have to be deployed with the app wheras a web application is a compiled app with a .dll in the bin folder and .vb/.cs files do not need to be deployed. There are many advantages to sticking with web applications over websites.

When im deploying I choose the publish option which generates a folder with just...

aspx files
web.config
PrecompiledApp.config
css files
bin folder containing :

• App_Code.compiled
• App_Code.dll
• App_global.asax.compiled
• App_global.asax.dll
• App_Web_nfqzsmrv.dll
• Recaptcha.dll

any other folders (images,js etc)


There doesnt seem to be any vb files anywhere.

mewso

Well thats interesting. When you deploy a website using x-copy for example you need to include the .vb files. When the site is then opened the site is compiled on the fly and a .dll is created in a temporary location. It looks like that publish option does that immediately but up to now the argument in favour of websites over a web application for example is that you can edit your .vb files on the server and have the site re-compile on the fly. This isn't a great practice but if you are using that publish option then you are better off using the web application option anyway.

Good discussion of it here - http://stackoverflow.com/questions/398037/asp-net-web-site-or-web-application

bigbadcon

I always just assumed I was using a web application

Didn't notice any difference until i was trying to find that setting in the project file.

Im wondering would the fact that they are compiled when they are in the Settings tab of the project file (in a web application) make enough difference to justify moving to web application?

Would I get the same result by putting my config values in the web config like this...

<appSettings>
<add key="Something" value="SomeValue"/>
</appSettings>

To be honest using the Website type has been really easy so far and I haven't noticed any limitations up until now.

Malice

Watch out if you do switch from Website to Web Application as I don't think the .aspx files get updated automatically with the CodeBehind attribute replacing the CodeFile one. That bit me a couple of weeks ago because you won't notice it until you deploy your project.

I don't know if it's any help but whenever I'm starting something new I always create a blank solution first. Then I add the necessary projects (web app, data access, unit tests) underneath that. Doing it this way you have more control over the paths although VS2010 might be better at this than the older versions.

mewso

It's up to you what you find easiest but if as you go forward you plan to move into enterprise level development for example and architectural approaches like domain driven design you won't be long in seeing the advantages to the web application over the website and it will become the norm to have multiple projects under the one solution that split out your application functionality into separate re-usable projects.

Malice

You can still use the Publish command the same way as described with a Web application so that's one thing you won't have to re-learn if you change your workflow around .
Another thing to watch out for is your production Web.config versus your local Web.config. You may have different settings e.g. for debugging or your database connection string so make sure you don't blindly deploy the local one. That's also something that bit me recently. It's also not a good idea to do deployments first things in the morning or last thing in the evening before you go home .

mewso

Malice wrote: »

It's also not a good idea to do deployments first things in the morning or last thing in the evening before you go home .

And never the day before going off on your holidays.

bigbadcon

This is just for some home website development i'm doing so its not going to turn into a huge project where I need unit test etc

I might be best just biting the bullet and doing it now before I come across any other issues with the "website" model.

In future I will definitely start with a web application.

Thanks for the answers folks, I appreciate it.

Malice

bigbadcon wrote: »

Thanks for the answers folks, I appreciate it.

I don't know if any of your questions from the first post got answered but you're welcome.