I'm a newbie with ASP.NET web applications. When I create an ASP.NET web app project, there's a file called resources.resx in the folder My Project. Working in my computer I can access this file and its content without any problem. But when I deploy the application I can't access this file. I've tried copying the file seperately, and the folder (My Project) seperately, with the file in it, but no luck. Is there a way to achieve this?
PS: I've read something about implicit localization and explicit localization but I'd like to know if it can be done this way.
It's embedded into your DLL when you build (compile). So you can't change it when it's deployed.
If you want to see it in your DLL, you'll have to use a tool like Reflector, dotPeek, etc.
You can read more on resources here, starting from the 'Compiling Resources into Assemblies' title (as you know how to use them by now).
Well my suggestion is to use global and local resources.
In production you'll have resx file stored in:
App_GlobalResources: available in all application
App_LocalResources: one for each folder you want resources.
They are XML files visibile and editable.
I use it to allow me to modify string localization resources without recompiling and deploying.
And you can also give a web interface to the end user to allow him to self translate and localize strings at runtime.
Related
Is it possible to setup configurations under ASP.NET project properties > Web > Servers for each user that downloads the source code?
Short answer: No.
Now the explanation:
These settings are stored in the project file.
Unless you exclude your project file (*.csproj for C# projects) from control versionning, these settings will be shared with all the team.
Before doing so, please note that this is not a solution, because a lot of information is stored in the project files, like files in the project for example.
The best option would be for other users to manually merge project files when there are modifications and commit/check-in the project file only when necessary.
I have a .net project whose part of the functionality is xls transformation.
I now want to move that functionality away from the main project to a separate class library project.
I have no problems moving classes and accessing them, but part of the resources that I wanted to move were xslt files that define the transformations. Those files were originally located in the special asp.net folder: App_Data and then accessed using Server.MapPath(~/App_Data/XSLT/anXsltFile.xslt)
I wanted to move those files to that separate library as well, but not sure how to approach it, and how to access those files within the class library.
Perhaps embed the xslt files inside your class library and stream read them as necessary to perform your transforms
http://support.microsoft.com/kb/319292
How to embed a text file in a .NET assembly?
http://blogs.msdn.com/b/alexdan/archive/2007/12/19/loading-embedded-resources-in-c-using-getmanifestresourcestream.aspx
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/1d341eae-fed4-408c-8791-96e96a5fd99c/
I think a class library, unlike a web site project, should not have file resources. It should supply the functionality to the web site project which will host the files.
I personally consider both the class library and the xslt files to be resources of the web site. Lets say you want to use this same class in a different app or web site, with different xslt files.
It's bad for re-usability.
I suggest you to use string constant in Web.Config with the Server.MapPath path and use these to load the xslt files.
I hope it's helpful
if you mantain the xsltfiles on the app_data, you must use
httpcontext.current.server.mappath("...your path...")
if you move the xslt files to the assembly too, you must get the Assembly resource...
I'm currently working on an ASP.NET project with multiple developers using Subversion for code distribution, but it's quite frankly totally messed up at the moment. The person who set up the Subversion repository have included config files specific to their computer, bin\* directories, and other such things.
I, being the guy who has to check out this repository and get it to run on my computer, am pretty frustrated by this since it's taken me a while to sort it all out to get it to compile at all. Now I'm thinking about writing a document for Subversion guidelines to send to the technical leader at my company so that we can get the process standardized and avoid these kinds of problems.
What I'm looking for is input on the guidelines. Here's the start for them, and hopefully we can make something good out of it:
The file structure should be set up to have third-party libraries checked in outside the build output directories (since they won't be included in the repository.) The name of this directory should be "Libraries".
No machine-specific files should be included in Subversion. Therefore, only a template of Web.config is checked in, which is customized by the developers to suit their machine. This behavior is included in Visual Studio 2010 by default and the individual configuration files (Web.Local.config) automatically have the template (Web.config) applied. The local configuration file still shouldn't be included in Subversion though, so long as it applies for a specific machine.
Solution and project files must not contain any absolute paths.
An ignore list should be set up. Start with:
'
*.user
obj
'
Example file structure for an ASP.NET 2.0 web site with a class library specific to the web site and a third-party library:
'
/trunk/
Libraries/
ThirdParty.dll
MyClassLibrary/
bin/ [Ignore]
obj/ [Ignore]
Properties/
AssemblyInfo.cs
SomeClass.cs
MyClassLibrary.csproj
- Holds references to third-party libraries. For example:
../Libraries/ThirdParty.dll
MyWebApplication/
bin/
ThirdParty.dll [Ignore; copied by build process]
ThirdParty.dll.refresh
- Contains "../Libraries/ThirdParty.dll"
Default.aspx
Default.aspx.cs
Web.config [Ignore]
Web.config.template
MySolution.sln
- Holds list of projects.
- Has reference information for projects.
'
An alternative to using Web.config.template would be to include a Local.config file from Web.config, but this might be less flexible.
When using a Web Application project rather than a Web Site project, the references will be stored in the project file instead of in .refresh files, so the bin/ folder will be ignored.
Can someone see errors in the above suggestions? Is something missing? Does anyone have suggestions for the ignore list? I just started with a couple of entries for now.
I think that you are a good step on the way. But why not put an ignore on the entire bin folder in /MyWebApplication, instead of the files? You wouldn't add your build output to subversion would you? I would definately consider that a bad practice.
Also, if possible, you could add the web.config file to subversion, but in the element reference a new file with appSettings: for example
<appSettings file="local.config">
Then have the local.config file be ignored by svn. That is how I always operate.
But of course that only works if every configurable parameter is in the appSettings (one of the reasons why I dislike the provider model, because all the providers need to get connection strings from a connectionString element, and you cannot reconfigure them to take a connection string from appSettings)
Edit: troethom enlightened me and pointed out, that you can also override the connectionString configuration settings in a separate file
<connectionStrings configSource="ConnectionStrings.config"/>.
So the thing that I would do is place the actual web.config file under subversion control, but let those other files that override the settings locally be ignored by svn.
You should add the .refresh files; not the real DLLs.
The Visual Studio project system sends a list of files that should be added to source control to SCC Providers. AnkhSVN is a Subversion SCC provider that uses this information to suggest adding these files (and not the other files).
VisualSVN and other Subversion clients that only look at file extensions don't get this information from ASP.Net.
(Note: if you remove the .refresh file, Visual Studio will add the DLL to the list of files that should be committed)
Is there any options to editing the resources in the App_GlobalResources folder? Once compiled, the directory is not included as part of the precompiled folder.
I read online that the App_GlobalResources Resources are compiled into a DLL for easy access. However, I want the administrator to be able to update the content of these files. Is the only way to convert these GlobalResources .RESX into LocalResources?
I don't know of any way to edit the files "in place" once they're compiled - but why not just make your changes, precompile the web again, and then just deploying the App_GlobalResources.compiled and App_GlobalResources.dll separately to your website? That should update the global resource DLL and should achieve what you're looking for, I think.
Marc
You can create a custom small resource editor application, this will be separate from your main application.
The GlobalResource Editor application will open a form which shows Keys in the first column and values in another column.
You can compile this application and copy and paste the app_globalresource file to your main application.
This way you can also ask your customer to use this application and teach him to copy and paste the resource file after compilation.
I have a web application that is becoming rather large. I want to separate it into smaller more logical projects, but the smaller projects are still going to need to access some of the classes in the app_code of the main project. What are some good methods to accomplish this?
Add a class library project with the common classes and add a reference to this project to each of the new projects.
So you'll have the following Solution layout
/webapp1
/default.aspx
/....
/webapp2
/default.aspx
/....
/lib
/Utils.cs
If you are only looking for a way to organize your files, then you can create a folder for each sub-project. This way you'll be able to get to the content of app_code and maintain a level of separation with very little rework.
If you are looking for the best way to do this, then refactoring your code to have a common Class Library based on what is reusable in the app_code folder and multiple, separate projects that reference that library is the way to go.
You may run into problem refactoring the code this way, including not being able to reference profile or user information directly. You are now going from the Web Site to Web Application paradigm.
http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Extract your common code from app_code into a class library which is referenced by each of your other projects.
I like the 3 Tier approach of creating a data access project, a separate business project, then use your existing site code as the presentation layer, all within the same solution file.
You do this, like posters before me said, by creating Class Library projects within your existing solution and moving your App_Code classes to the appropriate layer and then referencing the data access project in the business project, and the business project in the web project.
It will take a bit of time to move it all around and get the bits and pieces reconnected once you move so make sure you set aside plenty of time for testing and refactoring.
In CVS & Subversion, you can setup what I think are referred to as "aliases" (or maybe it's "modules"). Anyway, you can use them to checkout part(s) of your source control tree. For example, you could create an alias called "views" that checks out all your HTML, javascript, and css, but none of your php/java/.NET.
Here's an example of what I'm doing within my projects.
The basic idea is to have all common files separately from htdocs so they are not accessible by client directly and sharable.
Directory structure:
public_html
The only htdocs dir for all projects.
Stores only files which should be directly accessible by client, ie js, css, images, index script
core
Core classes/functions required by application and other scripts. Framework in other words.
application
Stores files used to generate separate pages requested by public_html/index script + classes common to all projects
config
Configuration for all projects, separated by project
templates
Template files separated from all other files
The public_html/index script is then used for all projects on all domains/subdomains and based on the requested URL loads proper pages...
A somewhat simple approach is to group the code in your app_code folder into it's own assembly. The only issue that you could possibly run into is if the code in your app_code folder is not decoupled from the elements on you pages (This is normally always a bad idea since it indicates poor cohesion in you classes).
Once you have your code in a separate assembly you can deploy it to any number of servers when you are upgrading you apps.