.NET Core 3.0 WPF "Copy Local" Assembly Issue - wpf

I've switched my current WPF application to .NET Core 3.0. Everything works fine, except one thing! I added a project reference to my app, and set the "Copy Local" property to "No" (I want to use it as embedded). And now, my application is compiling, seems to be running, than stop. I created a new .NET Core 3.0 WPF project, linked only one also new project, set the reference and the Copy Local to No, and it is the same.
Is it a bug or need some extra parameter in the project file? Any idea?
Thanks,
Zoltan

#mm8, trust me, it has sense. :) But never mind, I solved my problem. I replaced the ProjectReference with simple Reference + EmbeddedResource to the dll + AssemblyResolve, and it worked like in the .NET Framework project before.

Related

Reference System.Windows.Forms

Inside a console application (.net 4.5 using vs 2013), it's just not possible for me to add a reference to this lib.(System.Windows.Forms). Have started the new console proj many times from scratch to no avail. Any clues? this seems like a very simple task... but well, it's anything but. (thanks)
NO there is no such issue with console application when we add reference with Windows.Forms library.
Close your visual studio and try again.
Well.... this was interesting. Started playing with the property settings and set the target framework to 4 client and was finally able to add the library. Tried to run and it didn't, then changed it back to .net 4.5 full and set the build platform target as x86 as someone suggested here on SO... and yes !! it worked. So, basically playing around with those settings got me running, but still think it might have been an environment issue and not the platform itself. ... thanks !

Coded UI Testing of Silverlight in Sharepoint 2010

I am creating a Coded UI test for our system which runs on Sharepoint 2010. Part of the test sequence is creating a site; Sharepoint's UI for creating sites runs on Silverlight. Therefore, I need to create a Coded UI test for a Silverlight component which is part of out-of-the-box Sharepoint rather then part of our application. When I try to record a test, I get the following message:
No Silverlight controls where detected. Verify that the application under test is built using Silverlight assemblies with a version of 4.0 or greater and that a reference to the Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll assembly has been added to the project. For more information, see http://go.microsoft.com/fwlink/?LinkId=204562
I have two questions:
1) How can I find out the Silverlight version which Sharepoint components are built against? If they are built against Silverlight version 3.5 or earlier - I suppose the problem is unresolvable?
2) Assuming the previous question is answered - how can I make Sharepoint's Silverlight components reference the SilverlightUIAutomationHelper.dll library? That seems problematic at best to me...
Silverlight version installed on the test machine is 4; Visual Studio Feature Pack 2 is installed.
Thanks.
You can't make SharePoint's Silverlight components reference the automation helper library unless you have the source code and can recompile them. So the answer to your first question doesn't really matter.
You could modify Sharepoint XAPs to simply add Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll in there. You don't really need the code itself to reference it, it just has to part of the package. The XAP file is just a zip file so you should be able to modify this.
You will have to find where Sharepoint is getting the XAPs from and change the source (obviously you don't want to do this in prod boxes and there's even a license restriction for the Automation dll that prevents you from do it). You could also write a Fiddler AutoResponder to modify the XAP file and add the dll before it gets to the browser. For an example of this have a look at this AutoResponder:
https://bitbucket.org/mamadero/hackingsilverlightdemo/src/2fecb7b59dec/FiddlerAutoResponder

compile error when creating a new SL4 navigation app

I created a new Silverlight Navigation Application using Visual Studio 2010. I didn't make any changes to the code. Just Pressed F5 to run. I get the following error message:
The type 'System.Windows.Navigation.NavigationEventArgs' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.Controls.Navigation.dll' and 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.dll'
I right clicked the Silverlight Navigation Application folder in the solution explorer and changed its "Target Silverlight Version" from Silverlight 4 to Silverlight 3 and then ran the application (by pressing F5) and it works fine.
I've already spent a lot of time trying to fine a solution. I want to develop application using Silverlight 4.
Would really appreciate any help with this.
Regards,
Vivek
It sounds like you have Silverlight 4's runtime, but an older set of VS tools or an older SDK, or your project is somehow referencing the older SDK.
Basically, that type moved from the System.Windows.Controls.Navigation DLL (where it was in SL3) to System.Windows.dll (where it is in SL4). CLR type-forwarding should take care of this.
Since Silverlight version numbers on assemblies didn't change between SL3 and SL4 it can be somewhat hard to tell if you're in the situation where you have outdated tools/SDK. Check the last modified date on System.Windows.Controls.Navigation.dll and see if it looks like about the time SL4 was released, or check if the Frame control has a property called ContentLoader - if so, you have the updated bits (and my answer is thus not helping). If not, however, then try reinstalling the SL4 Tools and/or SDK and check that your project is referencing the v4 Navigation assembly.

WPF application is crashing after publish

I've upgraded WPF application to Visual Studio 2k8. App is .NET 3.0 which is set as a platform in the project.
If I build project & release confiuguration, app is running well.
If I try to publish it using ClickOnce, it is crashing because xaml resources couldn't be find.
Any idea?
Thank you very much.
P.S. It seem that XAML resources aren't really included in Resources in the assembly. If assemble is just rebuilded (without Publish) everything is ok and XAML are included in resources.
Have a look at the One Click Deployment options on your project.
On the Publish tab, have a look at the Application Files section.
Some files might not have been included.
It seems I solved this problem.
My application has been upgraded from V2k5 to V2k8.
If .NET 3.0 is target platform, the problem exists.
If .NET 3.5 is target platform, problem solved.
Thank you for your collaboration.

Why does VS.NET attempt to include Microsoft.Windows.Design.Extensibility for WPF and ClickOnce?

I built a WPF application in VS.NET 2008 using ClickOnce deployment. It ran great on any machine that had VS.NET installed, but my business users received an error: "Unable to install or run the application. The application requires that assembly Microsoft.Windows.Design.Extensibility Version 3.5.0.0 be installed in the Global Assembly Cache (GAC) first."
I was surprised to discover that this dll is not part of the standard .NET 3.5 SP1 client installation, but somehow, my application thought it was needed. I checked my Publish tab for the project and it showed up as a prerequisite.
Oddly enough, I was able to just remove this (and all of the other Microsoft.Windows.Design.* dlls) and it just worked everywhere. I removed them from my project entirely, and everything was fine.
Can someone explain why the VS.NET 2008 project wizard forced these to be included in the project, and more importantly, why ClickOnce thought they needed to be on the client machine to run?
This is just a curiosity question, but I'm sure I'm not the first to be bitten by it. Hopefully, this post will at least save someone else the headache.
Try to remove all references to *.Design.dll. In my case it was WPFToolkit.Design.dll.
This is old and the OP is gone, but I ran into this today, so I thought I'd mention that my solution was removing a reference to one of the WPFToolkit references that ends with .Design.
I had referenced System.Windows.Controls.Input.Toolkit, but also had a reference to System.Windows.Controls.Input.Toolkit.Design, which should not have been there. Removed it, and all was right with the world again.
A way to find out the code that is loading the assembly is explained here:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/755272f6-0e79-4a6d-ae50-4412d0f2bc4c
I found that I was using the SelectionCommands.Clear property which is inside the Microsoft.Windows.Design.Interaction namespace inside the Microsoft.Windows.Design.Extensibility Version dll.
Beats be why this dll isn't included in the .NET 3.5 install.

Resources