I posted this question on the MSDN forum but haven't been able to receive much of an answer, so decided to try it out here.
I'm having a problem with dependency libraries of a project not being copied to the output directory of a second project that references it, when the first library is mostly xaml. Here is a typical scenario when this happens
SolutionX
- SomeControls.Dll { contains wpf user controls }
external reference: WPFTheme.dll*
- MainApp.Exe
project reference: SomeControls.dll
Commonly what happens here is that when building the solution, WPFTheme.dll is not copied to the output directory of the MainApp.Exe project. (* this also works if referencing a third project instead of an external)
I usually use a post build event to handle this situations... but i found the problem was intermittent.
If I don't reference ANY of the classes in WPFTheme.dll in my c# code but I do so in xaml, then as said before the WPFTheme.dll library doesn't get copied.
BUT if i reference Any class (even just assigning them null) from some c# in the project (even backend xaml.cs class) - then everything works as one would expect.
So has anyone else encountered this problem? Is there a way to force the library to get copied if referenced by xaml?
Just to add more info... all this happens with libraries that show up as external in the project file with a relative path in the HintPath.
Thanks everyone,
K
I have this exact same issue with dependency injection through reflection, i get around it with post build events and when deploying nant scripts, sorry i couldnt be more help, look forward to seeing a solution, you can always just add the refs to the startup project directly, can get into some fun issues with that long term but it will work
Related
I have a WPF application built on .Net 4.8, Prism and Unity, using PackageReference in the project files. Every once in a while I update Nuget references to the newest ones. The packages related to Prism and Unity repeatedly have been a pain in the arse.
Now is such a moment again. Or rather, the past DAYS. I am trying to use packages like
Prism.Wpf 7.2.0.1422
Unity.Container 5.11.8
I keep bumping into the dreaded "The located assembly's manifest definition does not match the assembly reference", again & again in various variations. Seeing warnings like "Found conflicts between different versions of ... that could not be resolved", or "explicit binding redirect on ... conflicts with an autogenerated binding redirect".
I have been tinkering with this a lot, checking a whole dependency tree, removing, adding, or changing redirects, adding or removing packages. Of course searching on the web. It has driven me nuts. How to get out of this, and prevent it for the future?!
I don't know if this is combination of bugs somewhere, or just me not understanding how to use it. So I will put this as a question.
How on earth am I supposed to get things working?!
Set AutoGenerateBindingRedirects or not?
Set explicit redirects or not? If so, for which versions, to which other version? What about the publicKeyToken?
What about testing projects using MSTest, Moq, Appium, do they need a different approach?
Frankly, I was under the impression that using Nuget to install packages would just take care of all that, particularly using PackageReference. Well apparently, it doesn't.
I am at a loss. Is there anyone who can direct me to a valid approach?
Thanks in advance!
Currently I have a script that modifies nuget reference paths in old style csproj files. (for anyone that is interested this is due to building using different solutions which breaks the NuGet reference paths. I have reported it to Microsoft and it is currently in triage).
The script works correctly and does what I need it to, however I thought that this would be a good candidate for a Roslyn Analyzer with a Code fix.
I have played around with analysers and have been able to write several that can modify code within a project, but I am having great difficulty writing one that can work on the csproj file itself.
I have looked at workspaces (VisualStudioWorkspace and MSBuildWorkspace) however it seems to me that these will give you access to the various projects in a solution but will not give you access to the project file itself?
If anyone can give me a pointer to where/what I should be looking for, or if it is actually possible, i'd very much appreciate it.
Thank you
I get this error only at design-time.
At runtime everything works just fine. There is absolutely nothing wrong with I-Synergy.Resources class library.
I've searched for this error intensively but no solution.
(already tried:
reset settings VS
clear and rebuild solution
delete obj and bin folders
checked all references and dependencies
converted pcl to regular class library
)
As you probably know, there a lot of questions regarding the notorious "Could not load file or assembly" error many times creeping up our XAML designer.
After reading all the provided solutions, and sadly non of them working for me, I started to investigate this annoying issue.
I spend 4 days trying to figure this out. Luckily today I found the answer to my problem.
In my solution design I created several projects under the WPF application called I-Synergy. Among others I added assemblies named I-Synergy.Controls and I-Synergy.Resources (where I put all my Resource strings, static classes and images).
This last assembly seems to caused this error. Even I don't have any Resouces file (or any other local reference inside the WPF application) it somehow got confused with my I-Synergy.Resources project.
Solution:
I changed the I-Synergy.Resources project to I-Synergy.Library (assembly name and namespaces) and the error has gone. Probably the "Resources" name is a no-go and can be considered as a reserved word.
for a good reason we are prefixing our assemblies, with a prefix specific to each application :
e.g. if we have a project named "A" which is a dependency of an application named "MyApplication1" the latest will use a "MA1.A" assembly generated at build-time;
if another application "MyApplication2" has also a dependency on "A" we will transform the output of "A" as "MA2.A" when building the application...
So far so good.
Now we are starting to use WPF and we need to reference some types of "A" in the Xaml :
xmlns:a="clr-namespace:Some.Name.Space;assembly=A"
This is fine at design-time but at runtime there is no more "A" assembly but a "MA1.A" or "MA2.A" assembly,
so the application crashes.
Do you have any idea to workaround this issue without affecting too deeply the development process ?
E.g. loading the Xaml by hand and setting the prefix is not an acceptable solution.
Thanks in advance for any idea.
The .NET run-time needs to know what assemblies your assembly depends on. That is why you refer to the assemblies in code so the run-time knows where to find the class(es).
If you decide to rename the classes you will have to inform the CLR of the rename action.
The only way I see is by editing the source code or redirecting at run-time but WPF doesn't like that
for a good reason we are prefixing our assemblies
As much as I would like to believe you; I strongly suggest that you keep the names at compile time equal to the run-time version. It will be much easier to debug and trace errors. But as you didn't mention the reason I might be wrong here.
I am tasked with the localization of a Windows Phone 7 application. The first step is to replace the actual visible text with an ID and put the ID and the text in a resource file.
This is a very tedious work and I was wondering if there are tools for this to automate?
I am thinking along the lines of the gettext package and .po files used in the linux world.
Here is a codeplex project that may help you some. http://xlocalization.codeplex.com/. To use this method, each control that is to be localized must have the name property assigned.
I tried it with my existing project, and got results that were mixed, but in the long run, I decided to do it by hand. I don't remember specifically what the problems were that I had, but if you want to try it on a copy of your project, it won't take much time. If it works for you (and if your controls to be localized all have names), it could save you time.
Also, I don't know how familiar you are with localizing, but I wrote a blog on the subject that takes you from start to finish. It's at http://www.hopnet.mobi, click Blogs.
Hope this helps.
I know this will get a lot of traditional answers, but I would also like to put forward something completely original we tried (and succeeded) doing ourselves for more efficient localisation of Silverlight using Attached Properties instead of binding:
Localisation of Silverlight projects after completion
To pre-populate the database we wrote a XML parser to find our markers in all our project's XAML files (XAML is just a subset of XML after all). We could not find any existing tools to do what you suggested, but our requirements were simplified by our new method of localisation (no resource files and no horrid bindings).
(yes, this is almost the same answer as a previous one of mine today, but it seems to fit again).
Also for future reference keep an eye out for this tool: http://www.neovelop.com/ This tool will go in private beta soon and looks very promising. Judging from their preview movie this will do exactly what you asked for.