I've moved all image resources in a large multi-project solution to a new project specifically created for shared resources.
Adding a new reference to other projects where the shared images are used is working as expected. The image in the selected button below continues to appear in designer but with issues.
In VS Designer, I'm unable to select shared resources in the Image Editor, having instead to manually edit the designer code.
More specifically, in the Image Editor dialog (accessed from the 'Image' property of an existing control) I select 'Select from File/Resource..." to pop up the Select Resource dialog (shown). There, where I used to access all local project resources (Resources.resx), I would like now to add access to the new shared resources project. Ideally, I would add a second item to the dropdown shown which switches to the resx for the shared resources project.
How can this be done? Is there a better way?
I was able to share a resx file between project and using it in the designer in VS 2008 SP1 (I don't know other versions). Differently from other approaches, here resources are statically and dynamically shared, so at runtime there's really one copy of the shared resources. No storage or memory waste and it's easy to maintain with tons of projects.
Follow the guide and tell me if it works for you:
Create a class project Resources;
Create a resource file (go to Properties -> Resources of the project);
Move the resource file (default Resources.resx) to the root of the project;
Rename the resources file Resources.resx -> GlobalResources.resx;
Modify the resources file modifier to Public (double click on the resources file, "Access Modifier" -> "Public");
Copy any resource file to the root directory of the project;
Add any resource to the resource file using "Add Existing File" and selecting resources on the root directory of the project.
The project in the Solution Explorer should look like this:
Now in any project you need the resx file to be shared do this:
Add the "Resource" project as a dipendency;
Edit manually the project file (*.csproj) and add the following lines in the resources file ItemGroup (create a local resource file if you want to see it):
<ItemGroup>
...
<EmbeddedResource Include="..\Resources\GlobalResources.resx">
<Link>GlobalResources.resx</Link>
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>GlobalResources.Designer.cs</LastGenOutput>
<CustomToolNamespace>Resources</CustomToolNamespace>
</EmbeddedResource>
...
</ItemGroup>
Obviously, the "Include" attribute should be the correct relative path to GlobalResources.resx.
Use the resources in the designer as you was asking.
In my project, the following lines are generated and added to the project automatically when I do this:
<Compile Include="..\Resources\GlobalResources.Designer.cs">
<Link>GlobalResources.Designer.cs</Link>
<AutoGen>True</AutoGen>
<DesignTime>True</DesignTime>
<DependentUpon>GlobalResources.resx</DependentUpon>
</Compile>
If they aren't added, add them manually.
Now the project should look like this in the Solution Explorer (likend files should be marked differently):
Last two steps:
Click on the linked "GlobalResources.resx" and on the Properties set "None" as the "BuildAction". "Custom Tool Namespace" should already be set to "Resources";
Click on the linked "GlobalResources.Designer.resx" and on the Properties set "None" as the "BuildAction".
And you are done: at this point you should really be able to use the resources you added in the shared resx in the designer selecting "GlobalResources.resx" in the "Project Resource file" dialog of your question. And as told it's really shared even at runtime! In the Properties panel you should see the full Namespace and class of the external project. If you remove the dependency on the "Resource" project it doesn't even compile. If it doesn't work for you, insist until it works and in case tell me where the guide is wrong. It have to work! Let me know.
I came accross the same problem recently. Looked around MS documentation but couldn't find any good solutions. I was eventually able to get the image editor in the WinForms designer to recognize resource files from other projects using the method described below. It is hacky - if anyone has a cleaner solution they want to share please post. I have tested this on VS 2008 only.
Before I start I should say that if you just want to make the items in a Resources.resx file accessible to other projects, you can just edit its properties and set the access modifier for the generated class to public so it uses PublicResXFileCodeGenerator. The gymnastics below are only needed if you want to get the WinForms designers to pick up images inside this resource file as described in the post above from Douglas.
Say that your solution has the following layout. The default namespace for the various projects (right click on a project node in solution explorer -> Properties -> Application tab) is important here, so I've put this in brackets after the project names.
MySolution
SharedProject (default namespace = SharedProject)
SharedProject.csproj
WinFormsProject1 (default namespace = WinFormsProject1)
WinFormsProject1.csproj
WinFormsProject2 (default namespace = WinFormsProject2)
WinFormsProject2.csproj
You want to create a resource file in SharedProject containing images that can be used by WinFormsProject1 and WinFormsProject2.
First create a new Resource file in the root of SharedProject, let's call it SharedResources.resx. It is important that this file uses ResXFileCodeGenerator rather than PublicResXFileCodeGenerator for reasons which will become clear later.
Edit SharedResources.resx in Visual Studio and add the image resources you want to share. Visual Studio should also generate a class file for you inside SharedProject called SharedResources.designer.cs.
Your solution should now look like this:
MySolution
SharedProject (default namespace = SharedProject)
SharedProject.csproj
SharedResources.resx
SharedResources.Designer.cs
WinFormsProject1 (default namespace = WinFormsProject1)
WinFormsProject1.csproj
WinFormsProject2 (default namespace = WinFormsProject2)
WinFormsProject2.csproj
If you open up SharedProject.csproj with a text editor you should see the following entries:
<EmbeddedResource Include="SharedResources.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>SharedResources.Designer.cs</LastGenOutput>
</EmbeddedResource>
<Compile Include="SharedResources.Designer.cs">
<AutoGen>True</AutoGen>
<DesignTime>True</DesignTime>
<DependentUpon>SharedResources.resx</DependentUpon>
</Compile>
Now you need to make the resources accessible inside WinFormsProject1. To do this you'll need edit WinFormsProject1.csproj in a text editor because some of the properties you need to set are not exposed inside Visual Studio.
Open up the WinFormsProject1.csproj file and add the following inside an ItemGroup:
<Compile Include="..\SharedProject\SharedResources.Designer.cs">
<Link>SharedResources.Designer.cs</Link>
<AutoGen>True</AutoGen>
<DesignTime>True</DesignTime>
<DependentUpon>SharedResources.resx</DependentUpon>
</Compile>
<EmbeddedResource Include="..\SharedProject\SharedResources.resx">
<Link>SharedResources.resx</Link>
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>SharedResources.Designer.cs</LastGenOutput>
<CustomToolNamespace>SharedProject</CustomToolNamespace>
<LogicalName>SharedProject.SharedResources.resources</LogicalName>
</EmbeddedResource>
The key things here are CustomToolNamespace and LogicalName. By default Visual Studio uses the project's default namespace to name resources and to generate the *.Designer.cs file. Since SharedProject and WinFormsProject1 have different default namespaces the default behaviour causes the resource that is embedded in WinFormsProject1 to be incompatible with the *.Designer.cs file that is inside SharedProject. This can be prevented by overriding CustomToolNamespace and LogicalName.
Now do the same for WinFormsProject2.csproj. Go back to Visual Studio. It will notice that you've changed the csproj files and ask to reload the projects - choose "reload". You should find that you can now choose images from SharedResources.resx when designing forms in both WinFormsProject1 and WinFormsProject2.
Essentially what all of this does is make VS include the SharedResources.resx file from SharedProject in the WinFormsProject1 and WinFormsProject2 projects. There is only one .resx source file (in SharedProject), but when you compile the solution there will actually be three identical classes called SharedProject.SharedResources, one in each of the three assemblies, but since all have internal visibility they won't interfere with one another even if you add a reference between the projects.
SHARING RESOURCES BETWEEN PROJECTS IN VS2012
in 3 easy steps using the designer only!
create a project and add your resources to be shared as usual
create another project and 'add as link' the resources.resx of the first project in the 'add existing item' Dialog, accessible from the context menu
select images from the linked resource file as desired; this can be selected in the 'project resource file' pull down menu within the 'select resource' Dialog, accessible from the properties pane
VOILA!
For Visual Studio 2015+
There is an easy, straightforward way, that is not supported in the VisualStudio UI. So if you are not afraid of editing the project files, read on.
If you have not already done so, add a new shared project into the solution.
If you have not already done so, include the new shared project as a shared project reference to your peripheral project.
Note how this shared project is included in the peripheral project (.csproj file) in a straight forward manner:
<Import Project="..\Common\Common.projitems" Label="Shared" />
Thus, even though the VS UI does not expose it, everything in the shared project (.projitems file) is included directly into the peripheral project. Adding the following resource definitions to the shared project (.projitems file) will include them directly into your peripheral project. But, because the Resource element is not supported by the VS UI for shared projects, these files will be hidden and ignored in the IDE.
<ItemGroup>
<Resource Include="$(MSBuildThisFileDirectory)Resources\one 16x16.png" />
<Resource Include="$(MSBuildThisFileDirectory)Resources\one 64x64.png" />
<Resource Include="$(MSBuildThisFileDirectory)Resources\one.ico" />
<Resource Include="$(MSBuildThisFileDirectory)Resources\two 16x16.png" />
<Resource Include="$(MSBuildThisFileDirectory)Resources\three 16x16.png" />
<Resource Include="$(MSBuildThisFileDirectory)Resources\four 16x16.png" />
<Resource Include="$(MSBuildThisFileDirectory)Resources\five 16x16.png" />
<Resource Include="$(MSBuildThisFileDirectory)Resources\six 16x16.png" />
</ItemGroup>
Lastly, whereas your peripheral project resources might have relative paths (e.g. ".\Resources\main.ico"), these resources are compiled into your peripheral project with base ids, not absolute or relative. e.g.:
<Window x:Class="Common.Shared"
...
Icon="one.ico">
<Window.Resources>
<ResourceDictionary>
<BitmapImage x:Key="one64" UriSource="one 64x64.png"/>
</ResourceDictionary>
</Window.Resources>
You only need add a new class project with a RESX file where you include the resources (images, texts, etc). After in the other projects add a reference to this and use the Resource class name in order to access the resource needed, for example: Project.SharedImages.Upload_64x64 (the result is a Bitmap ready to use in this case)
Charlie's answer works great!
Just a small change: If you want to skip the last two steps, use this version of the included items when you modify a project file.
<None Include="..\Resources\GlobalResources.resx">
<Link>GlobalResources.resx</Link>
<Generator>PublicResXFileCodeGenerator</Generator>
<LastGenOutput>GlobalResources.Designer.cs</LastGenOutput>
<CustomToolNamespace>Resources</CustomToolNamespace>
</None>
<None Include="..\Resources\GlobalResources.Designer.cs">
<Link>GlobalResources.Designer.cs</Link>
<DependentUpon>GlobalResources.resx</DependentUpon>
</None>
Related
In VS 2017, or more accurately, the old project format used in VS 2017, each project had a 'Properties' folder with an AssemblyInfo.cs file which held things like project version, copyright, etc.
If you wanted to share some of that information between several projects, say all those in a particular solution, you created a AssemblyInfo_Shared.cs file, moved the shared properties into it, removing them from the original AssemblyInfo.cs file, then you would 'link' the shared version into each separate project.
Now when you build, information that is in AssemblyInfo_Shared.cs will be shared between all projects where as project-specific values would remain in the original AssemblyInfo.cs file.
However, in the new project format, these values are all embedded into the project's file, which now is a simple XML file. How can you share settings between projects now?
Properties (and even items) in the project file are processed by MSBuild, and can easily be refactored into .props and .targets files that are shared among your projects.
With the new project file format, MSBuild will automatically import files named Directory.Build.props at the beginning of your project, and Directory.Build.targets at the end - this includes searching up the folder tree until one of these is found. With this, it is very easy to share properties across all projects in your solution: simply create a Directory.Build.props file in the solution folder with your version properties, and every project will share those properties.
Is there a way to use a resource dictionary in multiple applications? What I have is a theme generator which uses merged dictionaries etc... works GREAT! I'm looking for a way to reference this project for the resource dictionaries into all my applications. (thus, having my theme engine in every File>New I decide to create) So far my research has led me to nothing.
Ok so I've found out that I can use the pack URI syntax to grab the resource dictionaries from application A and use them in application B
First I made a classlibrary and removed the default class1.cs
Then I added a new item (there was no option for a .xaml file so I added a .xml file and changed the extension)
Then moved the resource dictionary code into that file.
Referenced the new .dll as you would any other and now I can access the resource dictionary file using the below syntax.
<ResourceDictionary Source = "pack://application:,,,/App_A;Component/App_A_ResourceDictionary.xaml"/>
When swapping the files its the same syntax only omit the "pack://application,,," part.
Although this wasn't everything I wanted (so far) it has been the best solution I've found.
The part now that I want is the ability to house the swapping logic within the .dll. If I can do that... then my theme library can be PnP to any app with minimum fuss.
Can we change the default location for package templates? Or at least add more locations?
I would like to create some templates and add them to the source control but I'm not very keen on adding a file on the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems folder to the source control.
How do you deal with that?
I've never tried moving it, but when we built out templates, we had a Common project that contained common material (we're creative like that) like configuration settings for databases as well as template packages. The solution also had a start up project with nothing in it but a post build script where we'd copy the templates into the above path. That way people didn't have to worry about this "complex copying stuff" to get started.
copy /y "$(SolutionDir)\SQL\SSIS\PackageTemplate.dtsx" "$(DevEnvDir)\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems"
As rvphx reminded me, you will want to have people that use your templates to reset the Package ID. Otherwise, you greatly complicate reporting against your sysdtslog90/sysssislog table. The free visual studio add on, BIDSHelper, has a feature to reset the GUIDs from the project window. Another issue I ran into with our own templates was they would a physical file name that we provided but did not match the Package Name property inside SSIS. We'd either assign a junk physical file name and then rename it to the proper name or just remember to fix it in the package properties.
The template we've been using is pretty plain-vanilla (mostly a bunch of standard variables, connection managers and event handlers for SSIS 2008), and a couple of years back I wrote a NAnt script to build a simple one-package solution. Since the .dtsx format is just XML, it's not too terribly difficult to make a text template file out of a minimalist package and use NAnt's <replacetokens> task to replace things like package names and GUIDs. It's even easy to create unique GUIDs, since NAnt lets you embed C# code in your scripts:
<script language="C#" prefix="script" >
<references>
<include name="System.dll" />
<include name="System.DirectoryServices.dll" />
</references>
<imports>
<import namespace="System.DirectoryServices"/>
</imports>
<code>
<![CDATA[
[Function("create-guid")]
public static string CreateGuid()
{
return Guid.NewGuid().ToString().Trim();
}
]]>
</code>
</script>
<property name="PACKAGE_DTSID_GUID" value="${script::create-guid()}"/>
<property name="PACKAGE_VERSION_GUID" value="${script::create-guid()}"/>
To plainly answer your questions :
No you can't change it.
No you can't add more locations.
As described, you can script copy from one location to this folder. This is what most of us do.
I'm putting together a simple help system for my WPF app using XAML FlowDcouments (just .xaml files, no code-behind). I've simply added them to my project with Build Action = Resource, and I can load and display them as required.
Now, I'm trying to make it a bit more flexible, in that after the installation of the app, I want the user to be able to download additional (or newer versions of the existing) FlowDocument XAML help files. Given this, I'm now wondering where the best place to store these files is. A few questions/ideas:
Can I leave them as resource files, and overwrite or add new files as required? I can't find a example of how to add/edit resources at runtime on SO/Google. Is it even possible?
If not, is there a recommended location to store these files? They should be available to all users, so they can't go into the User's directory - they would have to go in the program directory. Does the program directory have write-access (I remember having issues with that before)?
Any other ideas?
Thanks.
The resource files are embedded into the executable and therefore you cannot change them.
As for a common place to put your downloaded help files, you cannot store them in "Program Files" since you would need admin privileges to write there.
I suggest you put them into SpecialFolder.CommonApplicationData (see http://msdn.microsoft.com/en-us/library/system.environment.specialfolder(v=vs.80).aspx), which is defined as "The directory that serves as a common repository for application-specific data that is used by all users."
I'm using MEF in silverlight to dynamically load some plugins from a secondary xap file. This secondary XAP file is built from a project that references various plugin projects, all of which are built against dlls that are already in the primary xap file.
As such, I want pretty explicit control over which dlls end up in this secondary xap. Including any dlls from the main xap file is redundant (and also causes issues with MEF recomposition). But Visual Studio seems to insist on including various dependent dlls even when the CopyLocal property is only set to True for the references to the plugin projects.
So far the only thing I've found that works is to add explicit references to probelmatic always-included dlls in the top-level project that builds the secondary xap, and set CopyLocal to False in the reference properties. But this is brittle as the dependencies change.
Am I thinking about this wrong? Should I just be building a separate xap for each plugin dll (in which case setting CopyLocal to false for all references seems to work)?
As well as setting Application Library Caching on your Silverlight project by selecting the "Reduce XAP size by using application library caching" option in your project settings (source) you need to have an extmap.xml file in the same location as your shared dll.
So if your dll was Microsoft.Expression.Effects.dll then you'd need to create (or copy) Microsoft.Expression.Effects.extmap.xml.
It looks like this:
<?xml version="1.0"?>
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<assembly>
<name>Microsoft.Expression.Effects</name>
<version>2.0.20525.0</version>
<publickeytoken>31bf3856ad364e35</publickeytoken>
<relpath>Microsoft.Expression.Effects.dll</relpath>
<extension downloadUri="Microsoft.Expression.Effects.zip" />
</assembly>
</manifest>
The version number should match the version number of the dll.
If you don't have the public key token you can replace that with null.
This will copy the dll to a separate zip file which can be then shared by several xap files or only downloaded once if it's not going to change when you xap file changes.
Take a look here: http://msdn.microsoft.com/en-us/library/dd833069(VS.95).aspx
Specifically, look at the section entitled "To configure an assembly for use with application library caching". It describes a method for doing something that's at least pretty close to what you're looking for.