ASP.NET application w/CSLA framework; Visual Studio 2008
I have a class library of business objects. I am storing the broken rules strings in the Resource file associated with the project (My Projects > Resources.resx). I added a new resx file to the project and named it Resources.fr-CA.resx to store the french language equivalents of the rules.
I am calling the strings with the My.Resources object, like this:
e.description = My.Resources.BrokenRulesString
This works like a charm when I run the application locally (i.e. hit "play" in Visual Studio). However, when I build and deploy the application to another environment I always get the values in the default resource file.
Even if I explicitly set the culture to "fr-CA" in the Resources.Designer.vb file, like this, the property returns the string from the default resource file:
Public ReadOnly Property BrokenRulesString() As String
Get
Return ResourceManager.GetString("BrokenRulesString", "fr-CA")
End Get
End Property
It looks to me like the application can't see the fr-CA resource file so defaults to the... default file. Any tips to get this working?
Thank you.
You need to make sure the satellite assembly containing your localized strings is deployed in the correct directory structure. See this MSDN article for details.
From the article:
After you have compiled your satellite assemblies, they all have the same name. The runtime differentiates between them based upon the culture specified at compile time with Al.exe's /culture option and by each assembly's directory location. You must place your satellite assemblies in expected directory locations.
Ultimately it came down to the fact that I hadn't added the proper Project Output Group (Localized resources) for the Business.Library project to the setup project. I added it to the bin folder and now the deployed application works like a charm as well.
Oded, thanks for getting my head pointed in the right direction. Cheers!
Related
Is it possible to relate/link to other project files within the comments of the source code (C# in this case) in Visual Studio?
I've found you can use file:// hyperlinks, but those need an absolute path (plus they won't open in the code editor)... there's also <see cref>, which works with R#, but that relates to a symbol that must be referenced by the current project, so that doesn't work in my case.
For my specific case, I'd like to somehow relate Entity Framework's entity POCOs to their mapping configuration class (which resides in other project file which is not referenced by the project where the POCOs are defined).
Absolute paths won't work since this project is being worked on several computers with different absolute paths.
There's also HyperAddin but doesn't seem to have been updated since VS 2008, I'm using 2015.
Any ideas, or add-ins you might have used?
You can automate it with Visual Commander. The simplest command (C#) that requires you to select the relative configuration class file path in the editor (like Project1\config.xml) before calling it:
EnvDTE.TextSelection ts = DTE.ActiveDocument.Selection as EnvDTE.TextSelection;
string relativePath = ts.Text;
string absolutePath = System.IO.Path.Combine(System.IO.Path.GetDirectoryName(DTE.Solution.FileName), relativePath);
DTE.ItemOperations.OpenFile(absolutePath, null);
I have a wix booststrapper project, which cannot be localized like the normal WiX project.
If I extract the hard code string from the booststrapper.wxs file, then the compiler output errors:
Light.exe : error LGHT0100: The localization identifier xxx has been duplicated in multiple locations. Please resolve the conflict
Has anyone some experience in boostrapper internationalization?
Would you give some suggestions?
This issue is discussed here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Votive-Light-LGHT100-error-when-more-than-one-localized-wxl-td7587802.html
In short, if you include two or more .wxl files you will see this error. The trick is to mark the extra localized wxl files as Build Action = None in the Properties window for the actual wxl files in the solution project tree.
If you are using a main one (or a copy) like RtfTheme.wxl, that one can remain as type Embedded Resource. This is the default type Visual Studio seems to assign wxl files added to the project but only one can ever be marked as such. So long as you have Payload elements that bring in the rest they do not need to be marked as Embedded Resource and, as experienced, it will fail the build if they are.
Additionally, the following post describes a very nice way to organize all these localization files: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-experiences-making-a-multi-language-bundle-td7208949.html
I have a problem when migrating a solution from VS2008 to VS2010. The problem is that the managed resources are not found in some cases in runtime, since they are not embedded with the correct name:
"Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "Production.ViewDocument.resources" was correctly embedded or linked into assembly "RSProcess" at compile time, or that all the satellite assemblies required are loadable and fully signed."
System.Resources.MissingManifestResourceException is typically thrown InitializeComponent in a call to ApplyResources on a resource that is created passing the type id. In my case the namespace is Production and the class name is ViewDocument. However, the resource generated (from the ViewDocument.resx) is named from the folder structure where the resx file is, in this case Production.folder1.folder2.ViewDocument.resources.
In VS2008 you could override the (default) logical name in in a setting on the .resx file, Managed Resources/General/Resource Logical Name. In VS2010 I cannot get this to work - it simply ignores this setting completly! Is there any ohter way of solving this?
One last resort would be to remove the current folder structure and move all files to the root project folder, but this seems to be quite a lot of work in my case.
Any suggestions?
I have found an answer to my own question!
A couple of things has changed in VS2010 that confused me. First, in VS2008 the names of the .resource files were affected by the project setting 'Resource Logical Name', in VS2010 the files are always named according to the root namespace of the project and the folder structure (extended namespace). Second, when migrating, these settings were blanked out, perhaps because we had used a macro $(InputFile) that has been replaced by %(Filename).
To fix this problem, I defined 'Resource Logical Name' on the project level (or you could use project property pages) to $(RootNamespace).%(Filename).resources. Note that the .resource files still get the extended names (defined by in which folder they reside). However, if you check the log file from MSBuild you can see that the logical name appears in the /ASSEMBLYRESOURCE swich to the linker in addition to the resource file name! After rebuilding, the ComponentResourceManager will now find the resources in 'InitializeComponent' using the type for the view, Rootnamespace.filename in this case. Also note that this assumes that your view classes are placed in files with the same name as the class!
In Visual Studio 2010, I want to create a project template that includes links to two files that should exist on the system. One of them is a common AssemblyInfo.cs file. Another is the strong name key file (*.snk).
I need these references to be relative, because each developer's workspace will be set up differently. Is it possible for the project template to somehow figure out where these files reside in each developer's environment?
From reading about templates, it sound like they're pretty static so I wonder if tricks can be done to do something like this. If nothing else, I can add bogus references that will cause compilation errors and force the developer to hook these files in. But if I can do it for them, that would be better.
You should set the CreateInPlace property to true in the vstemplate. The documentation says
Specifies whether to create the project and perform parameter replacement in the specified location, or perform parameter replacement in a temporary location and then save the project to the specified location.
If you want relative paths to work, you need the parameter replacement to occur in the place where you're creating the project, not in a temporary location.
Microsoft have confirmed that this is a bug with the extensibility model and project templates. I managed to get round this by using IWizard. I added the following code in the RunFinished method of my IWizard implementation:
//Get linked file directory
string coreDir = Path.GetDirectoryName(MyProject.FullName);
//Data folder
ProjectItem propertiesProjectItem = slSharedProject.ProjectItems.Cast<ProjectItem>().Where(p => p.Name == "Data").First();
propertiesProjectItem.ProjectItems.AddFromFile(coreDir + #"\Service\TheFileIWantToLink.cs");
This code links in a copy of TheFileIWantToLink.cs file to my shared Silverlight project (slSharedProject).
You could try to integrate a Wizard into your Project Template and set the Paths to the linked files. If i remember right you don't have to create an User Inteface; you only have to specify the correct replacements in the replacementsDictionary and VS will replace the values in your Template File. See this or this for further information.
Here is my problem. I made a WP7 application. I copied the project folder of this application in order to make a similar application without having to re-write the same code.
On the copied project, I changed the assembly information etc.., and I also modified the manifest.
The thing is that I can't deploy the copied project on my phone without erasing the original one. Seems like the copied app replaces the original one.
There must be some application identifier to change or something, but I can't find out what/where it is..
Is there a way to fix this, or do I have to start a new project from scratch and copy the files I need?
PS: Don't need to make a class library as it is mainly for testing purposes
Okay, I found out the answer. The thing is to modify the ProductId in the WMAppManifest.xml file. Replace it by a guid (You can generate guid with Guid.NewGuid(); ) You also need to modify the GUID in the assembly information. After changing both in the copied project, the application does not replace the original one anymore