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.
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.
I need to update dlls from site in my WPF project. As for .exe or msi file updating is everything clear. But what about dlls? I do not know what to start with or how it should look like... I implemented exe updating through xml file - read xml file from server and if version is higher - load this new version. As for dlls - there are a lot of them, they can be of new versions or new dlls at all... So, I have a question at all - HOW TO IMPLEMENT CHECK? (examples appreciated or just theory answers). And many small questions like If I need to read xml file - how to generate it automatically (to write all dllls not good idea). Waiting for your advice.
First, consider ClickOnce deployment.
If ClickOnce is not a good choice for you (it has its limitations compared to installers). You can implement you own self-updating mechanism.
Normally this is done by a standalone update util (let's call it update.exe), which checks your update website on a scheduled basis.
When you need to deploy a new version of your application (with updated exes, dlls and data files), you can define an XML that list the latest version information of all the files,
<files>
<file name="foo1.exe" version="2.3.0.2" hash="23ac4544490cb3bac23ac4544490cb3bac" downloadurl="youwebsite.com/dl/v23/foo1.exe"/>
<file name="subdir/foo2.exe" version="5.2.1.1" hash="..." downloadurl="..." />
<file name="bar.dll" version="1.3.0.2" hash="..." downloadurl="..." />
<file name="subdir/bar2.dll" version="1.3.0.3" hash="..." downloadurl="..." />
</files>
When update.exe is launched, it downloads and parses this xml to determine which files need to be updated, and download these files from the download url, validate the integrity of the files with the hash value, and stop the application to replace the original files, and then restart the application.
To answer your question as how to generate this huge xml:
Of course not edited by hand. Write a util that iterates through all the files in the install dir (the latest version), for each file, get the file version (use System.Version class), the file size (use System.IO.FileInfo class), generates a hash value from the content of the file (use something like System.Security.Cryptography.SHA256), and form the hugh xml (use XDocument/XmlDocument class).
I have a bunch of text, xml and other files (i.e. resources) that I need to access using servlets in java web app. For example, there is an xml file, a part of which is returned with a servlet by a user query. I am using Tomcat. What is the best practice to store these files and access them from java code?
1) What are the default folders where should I put them, do I need to put them into Web archive or into one of the Jars?
2) How to access the files from java code? How can I set the path to them so it will work in any environment?
P.S. I've read a number of posts related to this topic, most of which recommend to store resources in jars and access them using java.lang.Class.getResourceAsStream(String). It seems strange because classes and data should be separated.
It's perfectly fine to load static resources using the classloader. That's what ResourceBundle does to load the internationalized properties files for example.
Put them in WEB-INF/classes along with your class files, or in a jar inside WEB-INF/lib, and load them with the ClassLoader as indicated by the answers you already read.
That doesn't forbid you to place these files in a separate directory from the Java source files in your project. The build process should just make sure to put them in the appropriate location for runtime. The Maven and Gradle convention is to put the source files under src/main/java and the resource files under src/main/resources.
I have a common silverlight project. This project project, among other things, includes constants and static classes.
The silverlight App i have references this common library.
In addition, i have a handful of external modules that are loaded on-demand (via Prism). Each module is its own .Xap file and they too reference the common library.
So now each Xap in my silverlight application has a reference to the Common.dll.
Does this mean the common.dll is loaded every time a xap is loaded, or does it essentially mean only the main App's common.dll is ever loaded?
The ultimate question im getting at is this:
If i make a code change (bug fix) in the common.dll, do i have to release ALL Xap files or just the main App xap?
Thanks.
If you use Assembly Caching in all projects that reference the common dll then you'll just get one copy downloaded as it's own zip file. This way all the different XAP files will reference the same dll. Otherwise common.dll will be included in each XAP file that references.
You'll need to create a common.extmap.xml file for your common.dll which needs to be in the same folder from where the dll is referenced.
By default DLLs are loaded on demand. This means that you can't really guarantee which directory they will load from. This is a common issue among modular applications and one that there isn't a ready prescription for. It depends on requirements, essentially.
Some things you can do:
GAC the Common.dll in the target environment. This will allow you to control the versioning of that DLL centrally.
Release everything every time Common.dll changes (as you mentioned).
We have opted for number 2 (we treat our "Common.dll" as a contract assembly that changes rarely) in order to keep our xcopy deployments intact.
Number 1 might make more sense if you anticipate that code churn on Common.dll will be high or you want to keep your deployment schedules for modules completely autonomous (like if the modules were being developed and deployed by seperate teams with seperate build and source respositories, for example).
Edit: It looks like Silverlight has something to provide an xcopy variant of the GAC approach. ChrisF's answer is probably the way I would go with Silverlight (we do WPF, so that's a bit different). I'll leave this here for posterity.
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>