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.
Related
I have an ASP .NET Web Site Project that is being moved into TFS. There is a folder that is used for user uploaded files (e.g., company logos, excel spread sheets, etc.) that need to be kept. I'm trying to figure out a good way to manage these files without placing the folder in TFS (it's really big), and make it easy for new developers to grab the folder structure to their local machines for development.
I was thinking of doing the following and was wondering if this is a good way of doing it, or if there are better alternatives:
Create a script which will, when executed, create the folder structure of the storage folder. This would be placed in source control.
New developers could grab this file and execute it on their local machine.
To make sure the folder is added to source control, get the developer to remove it from their local project.
Store the folder on a NAS - no need for the files to be part of the source-controlled code.
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.
Have a question on "Temporary ASP.NET Files" folder; I have bit knowledge on what this folder is for as outlined by another thread in this forum
What is the "Temporary ASP.NET Files" folder for?
But recently, I am getting a warning while trying to build my new project as below
'c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\some folder\filename.cs' conflicts with the imported type ... using the one ...
Looks like that, two copy (shadow copy) of the same class (.cs file) file exist in two different version of temp folder and hence it's confusing as to use which one.
My Question is: Shall I go ahead and delete all contents from "Temporary ASP.NET Files" folder? Is there any side affect if I do so? Please let me know.
Thanks,
Rahul
If you close all of your instances of VS 2005, you can delete all of the files/folders within this folder. This folder is exactly as it's named -- Temporary. It loads all of the instances of your compiled files as they enter memory when they're loaded for a website. When you perform a "clean" on your solution it is supposed to empty the files in the folder relating to your open solution.
If you empty out your files and you continue to have this problem, then the problem will be related to how you have referenced projects and third party libraries within your solution.
If you take now your project, put it in a zip and send it to a friend, than he doesnt have the temporary folder for that project, and can build it too... So your main stuff should be in the project directory itself. Have you everything saved properly? Than close your Vs and clean the mess. (99% sure)
Have you tried to Clean your solution/project and recompile? That would only remove the compiled/temporary files associated with that project.
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)
I'm using a deploy project to deploy my ASP.net web application.
When I build the deploy project, all the .compiled files are re-created.
Do I need to FTP them to the production web server?
If I do a small change do I need to copy all the web site again?
From my own research, the .compiled files must be copied to the production server, but not needed to copied every time
from Rick Strahl excellent blog:
The output from the merge utilitity
can combine all markup and CodeBeside
code into a single assembly, but you
will still end up with the .compiled
files which are required for ASP.NET
to associate the page requests with a
specific class contained in the
assembly. However, because the file
names generated are fixed you don’t
need to update these files unless you
add or remove pages. In effect this
means that in most situations you can
simply update the single assembly to
update your Web.
Source
You can get rid of the .compiled files by using the aspnet_merge tool with the -r option.
Removes the .compiled files for the main code assembly (code in the App_Code folder). Do not use this option if your application contains an explicit type reference to the main code assembly.
There's nothing special about .compiled files: it's just the actual file with a .compiled extension on the end so that nothing happens if you accidentally double click it.
But if you're seeing .compiled files, you're publishing your app in such a way that it expects to be formally installed- it's not enough to just copy things to production. You have to run the installer program too. If this is an app you know is already deployed, that seems a bit unnecessary.