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!
Related
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
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'm creating a VS2010 extension (let's call it MyExtension). The UI for this extension is in a different assembly (MyExtension.UI), the extension project only contains boilerplate code to call the UI from the menu command.
MyExtension.UI contains localized resources (e.g. fr\MyExtensions.UI.resources.dll), but the VSIX package doesn't include these resources (although they are present in the bin\Debug directory).
How should I tell VS to include these resources in the VSIX package? I looked in the .vsixmanifest designer, but I can't find the appropriate option...
This is actually a bug that will be addressed in a future release. Fortunately, there is a simple workaround:
Select the Project Reference node to 'MyExtension.UI' in Solution Explorer and view the Properties (F4)
Change the value for "Output Groups Included in VSIX" to the following: BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup
#JohnField - I ran into the same error - "Could not determine the Full Name of the Assembly at '...'" - and wanted to list the fix here, in case anyone else runs into the same problem.
My issue was that I had both a ProjectReference to the referenced assembly AND I listed the Assembly as an Asset in my .vsixmanifest file. When you add a 'Copy To Output Directory' item to the referenced assembly, the VS SDK gets confused because it thinks the Assembly Asset you added was only for the Assembly. It sees the extra CopyToOutputDirectory item, and thinks it is an assembly and tries to load it.
The fix was to remove the Assembly as an Asset in the .vsixmanifest. This is not needed because the project is already being referenced, which includes the assembly in the resulting .vsix. Actually, the poorly name AssetType “Microsoft.VisualStudio.Assembly” is actually for template wizards.
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.
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!