Something strange happens to me today.
I’m working on a Multilanguage application using global resources.
I have several files, one for each language. i.e. companies.es.resx, companies.en.resx, etc.
Nothing special or different from any other ordinary Multilanguage app.
Today, the app fail and I traced the problem to be that HttpContext.GetGlobalResourceObject didn’t find the resource file.
After scratching my head for a while, I remember that yesterday, before I closed my Visual Studio, I delete a resource file that was garbage. This file was unused and in fact it was empty.
Just for “You never know” I create a new empty resource file, and Walla!!! Everything begins to work perfect again.
The ONLY difference with this file, is that is named without the language like test.resx.
I don’t get it, It is so weird.
Another funny thing is that when I try to access the resources with “Resources.” Test is the only resource I get.
Any Idea what is happening?
I’m using visual studio 2010 with MVC 3.
Thanks!
Edgar
Default resource file (without any language extension like companies.resx) is required with other language based files (like companies.es.resx or companies.fr.resx) when working with resources files for multilingual project.
Reasons: When no file exist, matching with the current culture then default file is used by .net. For example you have two language based files
.fr.resx for French
.es.resx for Espanish for instance
And if current user's language is other than these for instance Arabic then the default resource file will be used. i.e. .resx without any specific language extensions.
I had problem with resources in VS2010 too. After trying to reference non existing resource in the resources table Visual Studio was crashing. It didn't even let me to correct the wrong reference because it was crashing all the time.
I fixed this problem by deleting the wrong line in the file with regular text editor and after that running the VS again.
It seems that VS2010 has some issues with resources.
Related
I've just come across the weirdest behavior in Visual Studio 2010 while working with Resx resource files and I just can't wrap my head around it.
The problem is as follows: Visual Studio will not generate the designer.cs file for a resource file with a localized name (such as resource.fr.resx), but it works fine for other files with simple names (such as resource.resx).
Here's a snapshot of my visual studio project setup:
As you can see I just did a simple test with 3 resource files:
test.resx
test2.resx
test.fr.resx
The designer.cs files for test.resx and test2.resx are generated just fine. However test.fr.designer.cs is created but always blank, no matter what I do.
I have double and triple checked: the custom tool property is properly set for the localized file. All properties are exactly the same across all files (I'm using PublicResxFileCodeGenerator, but I get the same behavior if I set access modifier to internal and use ResxFileCodeGenerator).
Note: I've noticed that when created a resource file, Visual Studio normally defaults the access modifier to "Internal". However, when creating a localized resource file (resource.fr.resx) it defaults to "No code generation". Just found that interesting to note since it proves that visual Studio is treating the localized file differently for some reason.
--> Is there something I'm missing here? I would appreciate if anybody has some insight on the subject, this is driving me crazy.
While I haven't looked into this particular issue, I've had numerous other problems with ".resx" files. Visual Studio is sometimes buggy (handling ".resx" files among other things), and I've officially reported some of these to MSFT (since it affects my own commercial localization program). In any case, you shouldn't normally be naming things this way. It effectively violates MSFT's localization rules. Default language files shouldn't normally have an embedded language code, and it could be choking on it for this reason. I'd need to investigate, but what you should be doing is creating "Test.resx", which has a "Designer.cs" file, and then "Test.fr.resx", which doesn't. All default language strings are then placed in "Test.resx" and the corresponding French strings in "Test.fr.resx". In code, you then access the strongly typed name found in "Test.Designer.cs", and the string you get back will be the default language string unless you set "System.Threading.Thread.CurrentThread.CurrentUICulture" to "fr". You'll then get back the French version of the string from "Test.fr.resx", unless it's not found there (there's no translation), in which case you'll get back the fallback string from "Test.resx" (i.e., the default language string). This is how the hub-and-spoke model basically works.
We are working on an ASP.NET MVC 3 project and taking advantage of Razor syntax to resolve paths and what not.
We are also employing a UI design team who is responsible for maintaining the design of our pages through the use of CSS and modifying the HTML in the cshtml pages.
The problem is, they work exclusively on Mac laptops without access to a web server or a .NET IDE.
Initially, they were just providing us a straight .html file along with a .css file and we were manually merging in their work into our ASP.NET solution (e.g., replacing paths with Razor markup, etc), but as the project grows and we become more involved, we are looking for a solution that will save us from these manual merges.
I was thinking I could create some kind include script that would rewrite the paths depending on whether the UI designers were editing the file, or the .NET devs, but this seems archaic.
Anyone out there been in this situation before?
Razor is a templating language, and a pretty small one at that. Could your UI team familiarize themselves with enough of it to deal with their own links? I'm sure they are familar with your view hierarchy since they are going to be building it, so it shouldn't be much of a leap to explain how controller and action paths work.
Razor files can be edited outside of a .NET IDE just fine...any old text editor will work since it's not like there's anything you have to compile. You could provide them with an instance that they could copy their files to via a shared drive (cifs) to test them on. I don't see any reason for your UI team to be required to use Visual Studio.
You could just rename your .cshtml file to .aspx and reload it in VS and design away. when you are done, rename it to .cshtml
I've written a basic LanguageService extension for Visual Studio 2008 for my studio's proprietary scripting language. It works perfectly fine, and I've implemented a basic symbol table to keep track of script definitions and calls allowing for goto definition functionality.
The problem I've run into is that I only know how to parse the current active view, and I'd like to scan the entire solution's contents so that the user can goto the definition of a script defined in a file they have yet to open and have parsed. I've figured out how to generate a list of all files in the solution, but now I need to create a new Microsoft.VisualStudio.Package.Source which requires a Microsoft.VisualStudio.TextManager.Interop.IVsTextLines and I have no idea how to create a new one based off of the file I have.
Maybe I'm going about the problem the wrong way and someone can point me towards a better way to cause a file to be parsed by the LanguageService.
Regards,
Colin
Poking around I found that the reason Visual Studio needs a new Source is that it's keeping an internal list of them, and they're like the view into the text file held by the editor.
I came to the conclusion that files that are closed do not need IVsTextLines or to be entered into the VS internal list of Source files because I'm not doing any operations directly on them, all I care about in this case is to build a table of symbols and their corresponding TextSpan. So instead I created a new API for my parser that just took in a string and built my AST instead of grabbing the text from a ParseRequest, and only worried about specific types of symbols I needed to record. I then pushed this into a BackgroundWorker.
So I guess I was going about the problem in the wrong way. Although it does seem weird I can't just trigger a file to be opened into the Source list.
Interestingly I asked this question to Microsoft on their support forums and they advised me I had to purchase some service and support plan for them to answer my question.
This is not a work-stopper in any way, but I thought I should ask anyway because it is a little annoying. Let's say I create a new project and start putting source files in a directory other than the default that shows up the first time. Afterwords, whenever I open the project, I have to navigate to the source directory once during that session. Like I said, not a big deal (but if solvable, then it's icing on the cake). Quite a few times I absentmindedly put the source file in the default directory and end up committing that file to the SVN and if I am lucky, going through all the files, removing them, then adding them again.
So my question is, is there any way to specify the default source directory on a per project basis?
I have run into the same nuisance. I like to put the public interface header files for a library in a separate directory, but end up with file directory typos because I forget to navigate to the correct directory when saving a new file. Unfortunately, Visual Studio does not offer a setting to change the default directory for new C++ source files.
I had the same problem when I started using build systems (CMake, Premake) which requires me to keep my project files separate from my source files, which hampered my workflow.
Although changing the default source directory seems impossible, if you aren't afraid to spend money, the workaround I found was to use the Visual Assist extension.
You can bind a shortcut of your choise to the Create File command which creates
a new file relative to the directory or your open file.
I'd also recommend to base one's workflow around the wonderful
Create from Usage command (which I think greatly boosts
productivity) which almost eliminates the need to manually create files.
The extension is great, albeit a bit costly. I would love to see Microsoft incorporate these features directly in the IDE eventually as they are found vanilla in a lot of other IDEs e.g. Eclipse, Intellij.
There might be some free extensions available that does the same thing, but I haven't found any.
Changing the Default Project Folder may help. This page demonstrates how to change the default for Visual Studio 2005, and it should be the same for later versions.
I'm trying to build a small VS 2005 solution I've just checked out of source control, and I'm getting this easy to understand error:
...\AssemblyInfo.cs' could not be
opened ('The system cannot find the
file specified. ') (The file is fairly
obviously missing)
Because this file's automatically generated, I've never paid it much heed before, and in VS 2003 (which I still work with day to day - pity me) it never seems to matter if it's missing.
So 2 questions:
1. How can I get VS 2005 to regenerate the file.
2. Could anyone explain to me in a couple of sentences what the assembly info file is all about, why it's generated, why it's a good idea to have an automatically generated file critical to my solution building etc etc.
Thanks - Andrew.
Edit: OK, I've googling some more, and it's probably significant that this is in an Nunit Test Project.
Update: Deleting the reference in solution explorer an Alex suggested did the trick, and the project now builds, but I'm not entirely happy with that as a solution. If the file is so unimportant, why is it generated in the first place? And if the file does perform a vital task, what am I missing out on by just deleting it?
Also, is it even possible to get it back? Either by getting VS to regenerate it, or by manually hacking one up (possibly using another as a template)?
This file contains assembly-wide settings like assembly version, name, etc. It is automatically generated when you change those settings using properties pages of the project. You should have this file in the project with sort of transparent icon (I think it is in resource folder or something like this by default). Locate it in the project tree and delete it. Visual studio will stop looking for it during build.
PS: assuming the path starts with .. and not ... then this file should be located one folder up from the project in the source control. So you can try looking there.