How do I reference the FontAwesome.WPF dll from the OtherProject in the Test project.
In the OtherProject I reference it like this:
xmlns:fa="http://schemas.fontawesome.io/icons/"
I know how to reference the project itself:
xmlns:fa="clr-namespace:OtherProject;assembly=OtherProject"
But I think the namespace should change, however I don't know to what and where to find it?
This is the FontAwesome.WPF in the object browser:
I don't know how the first reference would relate to this or might help me or if this is even possible?
So what I want is calling this:
<fa:ImageAwesome Icon="Flag" VerticalAlignment="Center" HorizontalAlignment="Center" />
Without installing the NuGet package in the Test project.
You should read the following accepted answer.
MSBuild doesn't copy references (DLL files) if using project dependencies in solution
In short, you have two options:
Install the NuGet package in the test project as well.
Add some code (not only XAML markup) in the OtherProject that references a type in the FontAwesome assembly.
Then the assembly should be copied to the test project's output directory.
Related
I have a simple WinForms app that I'm trying to package with MSIX. The app itself requires additional files that when I build the MSIX App Project doesn't copy/include.
Specifically this LIBVLC folder that gets included during the WinForms app build itself.
If I manually copy that folder over into the AppX build folder, everything works. Obviously I'm trying to automate including that folder.
Folder manually copied over in screenshot below:
How can I accomplish this? GitHub minimal repo:
https://github.com/aherrick/MSIXWinFormsLIBVLC
I suspect that this line is your issue : https://github.com/aherrick/MSIXWinFormsLIBVLC/blob/0e717828a16e796a7a27e415cf45d33a50327da9/MSIXWinFormsLIBVLC.AppPackage/MSIXWinFormsLIBVLC.AppPackage.wapproj#L80
The nuget package isn't really well understood by the build tools as those are native files that we collect "before build". It seems to cause issues when a project references a project that references the nuget package, and the usual workaround is to reference the nuget package directly in the topmost project.
Is it possible to reference a nuget package in a .wapproj ?
If it isn't, that's an issue for this repository https://code.videolan.org/videolan/libvlc-nuget/ . Contributions welcome
My goal:
I want to use Interaction Triggers in that way:
<i:Interaction.Triggers>
Therefore I opened the Nuget and installed this:
After this the two references (Microsoft.Expression.Interactions and System.Windows.Interactivity) were added to my project. The path of those points to the package directory (Blend.Interactivity.Wpf.1.0.1340.0) in my project folder.
The problem:
The namespace is not recognized by Visual Studio. I tried:
xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
Intelisense is not recognizing any elements inside the i-Tag.
The .Net version of the project is 4.5.2.
I tried to remove and reinstall the package.
Any ideas what went wrong here?
In most of the Helix 3d wpf examples (source files) posted in GitHub, there is a reference to "Example Browser" (using ExampleBrowser;) in the .cs files. I cannot find any assembly defining a reference to this namespace in the packages obtained from Nuget (HelixToolkit and HelixToolkit.Wpf). I commented this line out and solution builds OK and app runs OK.
Anyone has any idea where this line comes from or where the assembly is?
Thanks in advance.
ikonuk
If you clone the repo of helix-toolkit you'll see that in the Helix-Toolkit solution there is a separate project called example browser for showcasing various use cases. Nuget packages only contain the helix-toolkit itself without the examples
By adding the <PackageReference Include="SourceLink.Embed.AllSourceFiles" Version="2.8.0" PrivateAssets="all" /> tag in my .csproj file, I was able to embed the source files of my library in the nuget package. This was good.
However, when I try to debug into the library from client code, Visual Studio was unable to locate the source because the files it was looking for had absolute paths from the build server, e.g.
Locating source for '/scratch/teamcity/work/d5de3351444bb38d/<ProjectFolder>/<SourceFile.cs>'
Is there something I overlooked that would make this process work correctly?
Update
It appears that the package reference to SourceLink wasn't actually doing anything. Just setting the project to compile an "embedded" DLL was sufficient to get the absolute paths to the source included in the file.
I am building with dotnet on Linux. Is there a compatibility issue with SourceLink.Embed.AllSourceFiles in this context?
I have the SL Control toolkit installed on my machine and I have added a reference to the toolkit DLL (System.Windows.Controls.Toolkit.dll)
I like to have all my external dependencies in a lib folder under the SL project, so I copied over the DLL from the installation dir of the control toolkit to the lib folder, but if I try to add reference to the DLL from this location, VS is still picking up the reference from the installation dir.
What gives?
I ran across this problem everyday. The easy (it feels that way after some time) solution is to unload the project (right click>Unload Project) then right click again en select Edit. Find a reference that is point to another assembly in your lib folder, copy that Xml element and change the 'Hint' path to your assembly.
It will look something like:
<ItemGroup>
<Reference Include="Ninject">
<HintPath>..\..\Ninject.dll</HintPath>
</Reference>
<Reference Include="System" />
<!-- other references removed for breviti-->
</ItemGroup>
The installed DLLs are always searched first, even if you add the DLL by browsing. The path in the properties window (for your added reference) would have shown the "installed" version instead immediately after adding the reference to your copy.
A build machine would not have the toolkit installed. You could uninstall the toolkit and organise the DLLs yourself if you really need that sort of behaviour.