I am following the basic starter example shown here:
https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/host-custom-control-with-xaml-islands
I have followed it as closely as I can. I can get it working if I put my user control in with the UWP app (different to the example) but not as it is with the usercontrol in the class library.
Firstly, when I run the example as it is, I get:
"WindowsXamlManager and DesktopWindowXamlSource are supported for apps targeting Windows version 10.0.18226.0 and later. Please check either the application manifest or package manifest and ensure the MaxTestedVersion property is updated."
The only solution I can find to this was to add a manifest file to the wpf project containing:
<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 -->
<maxversiontested Id="10.0.18362.0"/>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
</application>
</compatibility>
</assembly>
After that, I did not see that error, but when the wpf form loads, I see "Cannot create control of type ClassLibrary1.MyUserControl1", but no clues as to why.
Anyone know what I am doing wrong, how to find out what the problem is of know of any examples that do work?
I downloaded your project package and I found that you missed a step.
It's the forth step in Create a custom UWP control
Before the closing element, add the following XML to disable several properties and then save the project file. These properties must be enabled to host the custom UWP control in a WPF (or Windows Forms) app.
<PropertyGroup>
<EnableTypeInfoReflection>false</EnableTypeInfoReflection>
<EnableXBindDiagnostics>false</EnableXBindDiagnostics>
</PropertyGroup>
After you add this code to ClassLibrary1.csproj, clean up the class library and rebuild it, then everything will work.
Best regards.
Related
I just upgraded my .net core 2.0 project to 2.2. To my knowledge, I didn't change any other settings, but now when I publish to my file system, it publishes a ton of folders and dlls that it didn't before.
Do I need to publish them? If not, can I suppress their output?
Here is my publish profile settings:
Here is what the output directory looked like before the upgrade:
Now, here is just a snippet of what the output directory looks like:
Introduction: This issue seems to result from .net core 2.0.
From the picture you shared above. I know you choose Framework-Dependent Mode.
In this mode, generated files should be like what you have in picture1. And if your choose self-contained mode, generated files should be like what you have in picture2.
But in .net core2.0, there seems to be some different. When we publishing projects in .net core2.0, or just upgraded from 2.0 like yours. We must set self-contained property to false explicitly so that the Framework-Dependent mode can work normally.
Do I need to publish them?
No, you don’t need to publish generated files from self-contained mode as you choose framework-dependent mode.
If not, can I suppress their output?
Here is one workaround:
Looks like you use VS IDE to publish it, when publishing make sure choose 'create profile'. So we will have a PublishProfile, we can find it below Properties in Solution Window. Open the FolderProfile.pubxml and add the <PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest> in the PropertyGroup. Also, we can set the <DeleteExistingFiles>false</DeleteExistingFiles> to true.
After that, publish the project again the issue can be resolved.
The final format of PublishProfiles looks like below:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
<publishUrl>bin\Release\netcoreapp2.2\publish\</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
</Project>
In addition: You can find more info from this issue. Thanks to natemcmaster. His advice do work at my side.
Yesterday I did the update to VS (15.3), .NET Standard 2.0, .NET Core SDK 2.0 and so on. After that my current Xamarin Forms project broke. Most packages lost compatibility (although I did not change the standard1.4 version of the library). So I created a new standard1.4 library through VS (as stated here: https://xamarinhelp.com/visual-studio-2017-net-standard-xamarin/). I copied the code from the old Xamarin library to the new one and added all packages.
The problem now is that all xaml and xaml.cs are splitted and I get compile errors. I cant connect the files as I was used to (How can I connect xaml and xaml.cs files), because the csproj has completely changed through the evolution of netstandard. Whats even more astonishing is that even when I add a new xaml page to the project, the xaml and xaml.cs files are splitted. How can I fix this behavior?
Found the solution, through my post on the Microsoft Developer Network (https://developercommunity.visualstudio.com/content/problem/96027/vs-153-netstandard-xaml-and-xamlcs-seperated-and-c.html)
Credit to Long Nguyen (see source):
Fixed it by following this article:
https://oren.codes/2017/04/23/using-xamarin-forms-with-net-standard-vs-2017-edition/
In the .csproj file, you can see he declare the .xaml pages:
<ItemGroup>
<!-- https://bugzilla.xamarin.com/show_bug.cgi?id=55591 -->
<None Remove="***.xaml" />
<Compile Update="***.xaml.cs" DependentUpon="%(Filename)" />
<EmbeddedResource Include="***.xaml" SubType="Designer" Generator="MSBuild:UpdateDesignTimeXaml" />
</ItemGroup>
After doing the changes to the csproj, it should pick up the xaml and xaml.cs files again.
I'm making an Setup project using WiX and my project uses the Newton.JSON library. I've not referenced the Newton library in WiX however it is fully referenced in my application.
This is the error I'm receiving (Sorry for the image, unable to copy paste the code) :
Could someone please save me, I've been pulling my hair about this for a few hours now, nothing I try seems to work. Tried deleting all bin and ob files, deleted packing.config, deleting the bin and obj from both my project and the installer project. Then trying to reinstall Newton.JSON. Still no joy.
Here is my package.config file currently :
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Newtonsoft.Json" version="6.0.3" targetFramework="net45" />
</packages>
Here is the link to my setup project xml - http://nopaste.info/bcbc2048a6.html (for some reason SO doesnt let me add it as code.
As you can see the packages property does indeed have the newton.json reference.
Anyone have the same issue at all? So it isn't just me?
Try to assemble all dependencies manually in the folder you wish to install to and try to run the application from there to see what files need to be installed. Register any components that need registration such as COM Interop files. Most .NET applications work if you copy all referenced assemblies to the installation directory. The EXE will use the local folder as default search path.
You need to include dependencies in your installer package. WiX doesn't automatically pull in project references.
I'm trying to publish the files of a project I just created in Visual Studio 2012.
When I click publish,
the following window is displayed
Already created a new web project (same type, asp.net mvc 4) and tried to make the same change and everything worked.
Apparently this only occurs on this project!
Already closed the "VS" and opened again as I restarted the PC ..
Any tips?
Also check your ProjectTypeGuids in your .csproj file. I had a similar problem, though not exactly the same, and the source was because other team members had opened the project in VS2012, while I was on VS2010. VS2012 forces you to transform an MVC2 site into an MVC3 site, which VS2010 then cannot handle when it comes to publishing.
Poor backwards compatibility if you ask me.
I have answered this question here. Basically, you need to repair your Visual Studio Installation.
Do you have a <clear/> element in your <connectionStrings> element in your web.config? If so, delete it and you should be able to publish.
I also faced same issue while publishing our project in Visual Studio 2010.
For me, deleting all the files from bin folder worked.
For me, deleting the files with extension .pubxml & .pubxml.user from src folder is what fixed it. I had to re-configure publish settings afterwards. Bear in mind that you may have to delete them a couple of times and restart the IDE for this to work.
OK, I've just finished solving this problem. It's an error in the web.config. Checking the output it pointed to Microsoft.Meb.Publishing.targets, line 2309, as the source of the error. If you check that line by double clicking the output, it will show the ParameterizeTransformXml node. This makes the sustitutions between release/debug.config and the web.config published.
In our case a Merge on git caused the problem on the web.config file. But as JiffyLueb said, any other unexpected tag can cause the problem.
For me it was the length of Directory on where the whole project sits.
I moved it into somewhere closer to root and it went ok
I had similar problem. File *.pubxml in PublishProfiles folder had saved properties for publish method. There was WebPublishMethod FileSystem and publishUrl tag was some non-existing folder on my computer (it exist's on my other computer).
<?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your Web project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit http://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>c:\temp\someFolder</publishUrl> // this folder didn't exist on my computer
<DeleteExistingFiles>True</DeleteExistingFiles>
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
</PropertyGroup>
</Project>
My code is a plugin for a specific Application, written in C++ using Visual Studio 8. It uses two DLL from an external provider. Unfortunately, my plugin fails to start because the DLLs are not found (I put them in the same directory as the plugin itself).
When I manually move or copy the DLLs to the host application directory, then the plugin loads fine. This moving was deemed unacceptably cumbersome for the end user, and I am looking for a way for my plugin to load its DLLs transparently. What can I do?
Relevant details:
the host Application plugins are located in a directory mandated by the host application. That directory is not in the DLL search path and I don't control it.
The plugin is itself packaged as a subdirectory of the plugin directory, holding the plugin code itself, but also any resource associated with the plugin (eg images, configuration files…). I control what's inside that subdirectory, called a "bundle", but not where it's located.
the common plugin installation idiom for that App is for the end user to copy the plugin bundle to the plugin directory.
This plugin is a port from the Macintosh version of the plugin. On the Mac there is no issue because each binary contains its own dynamic library search path, which I set as I needed to for my plugin binary. To set that on the Mac simply involves a project setting in the Xcode IDE. This is why I would hope for something similar in Visual Studio, but I could not find anything relevant. Moreover, Visual Studio's help was anything but, and neither was Google.
A possible workaround would be for my code to explicitly tell Windows where to find the DLL, but I don't know how, and in any case, since my code is not even started, it hasn't got the opportunity to do so.
As a Mac developer, I realize that I may be asking for something very elementary. If such is the case, I apologize, but I have run out of hair to pull out.
You are not asking for something very elementary. Windows simply does not support what you want.
You have some options to work around this issue:
Create two DLLs. Your plugin implementation dll, that statically links against whatever other dlls you need. And a simple "facade" dll that is loaded by the hosting app. The facade dll gets to call SetDllDirectory then LoadLibrary to load your implementation dll with the required search path, and then, for each plugin exported function, it implements a stub function that uses GetProcAddress to just pass the call straight to your implementation dll.
If the plugin interface is complicated, but the dll interface you are using is not, then:
Give up and just use LoadLibrary (with an explicit path) and GetProcAddress to access the functionality in your satellite dll(s). Pain.
The final option is the least documented and most badly understood by windows programmers. Basically we use the windows version of a technology built to support .NET: Side by Side assemblies. Don't be frightened. A "Side by Side assembly" is very simply a regular old dll, but with a accompanying .manifest file that provides some extra information about it.
The reason we want to do this is the search order for dlls that are linked in via the SxS technology is different to the regular dll search order :- Namely - after searching c:\windows\WinSxS, windows will search the same folder as the dll that references the dll, NOT the folder of the exe.
Start by taking an inventory of all the satellite dlls your plugin dll needs to link to, and create an "assembly" from them. Which means: create a .manifest file with a bunch of file= nodes. You need to give the assembly a name. Lets call it "MyAssembly".
Create the file "MyAssembly.manifest" in your dll's folder, with contents similar to the following: (listing each of the dlls you need to include)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity name="MyAssembly" processorArchitecture="*" type="win32" version="1.0.0.1"/>
<file name="firstrequireddll.dll"/>
<file name="2ndrequireddll.dll"/>
</assembly>
Now, thats your assembly manifest. We are half done.
The next half is to actually get your dll to use the assembly, and to do that you need to add a manifest resource to your Dll file. That manifest ultimately needs to contain the following content :-
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="MyAssembly" version="1.0.0.1" processorArchitecture="*"/>
</dependentAssembly>
</dependency>
</assembly>
Apparently application manifests (which is a confusing name when embedded in a dll), are also allowed to use a <file> node, so it might be possible to skip creating an assembly, and just go with
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<file name="firstrequireddll.dll"/>
<file name="2ndrequireddll.dll"/>
</assembly>
as the dll's manifest. I havn't toyed with that iteration yet, so Im not sure how that alters the normal dll search path (if at all).
Without knowing your development environment, its hard to know how to advise you how to add a manifest to a dll. If you are editing a .rc file and entering the manifest by hand, know that in Dlls the resource id to use is 2, not 1, which it typically used in exe examples.
If you are using DevStudio 2005 or higher, there is a handy #pragma directive that will make everything magically have the correct id's and be in the correct places.
If the project settings are on their defaults, VS2005 and up will automatically generate, and embed a manifest as appropriate. this #pragma will add additional assembly dependencies
to the generated manifest :-
#if _MSC_VER >= 1400 // VS2005 added this directive
#pragma comment(linker, \
"\"/manifestdependency:type='Win32' "\
"name='Company.Product.Subsystem' "\
"version='6.0.0.0' "\
"processorArchitecture='*' "\
"language='*'\"")
#endif
Delay loaded DLLs are your friend in this situation. I faced the exact same problem a while back and it's actually rather simple. You specify to the linker (/DELAYLOAD flag) which modules are delay-loaded and basically they modules are not listed as explicit imports in the PE header so the loader won't complain when it cannot find the said modules and all the calls to functions from those modules are wrapped in a stub which ensures the module is loaded & the function is found.
So, let's say you wished to delay load the XmlLite library. First you'd specify /DELAYLOAD:XmlLite.dll in the linker flags. Then in your module's initilization function (preferably DllMain) you'd unpack the XmlLite DLL into a temporary folder and then call LoadLibrary on it. From there on it, each call to any function exported by XmlLite.dll would be resolved automatically.
Use GetModuleFileName() to find the path where your dll is located.
Then use SetDllDirectory() to add that path to the dll search path.
Assuming native code and that you can use explicit run-time dynamic link (rather than any form of implicit link), use GetModuleHandle and GetModuleFileName to find out where your dll is running from.
HMODULE hModule = GetModuleHandleW(L"RunningDll.dll");
WCHAR path[MAX_PATH];
GetModuleFileNameW(hModule, path, MAX_PATH);
Then replace the base name of the dll with the name of the plugin.dll you want to load.
CString plugin(path);
int pos = plugin.Find(L"RunningDll.dll");
plugin = plugin.Left(pos);
plugin += L"pluginName.dll";
Call LoadLibrary on the generated string.