Package Manager gives this output:
Resolved actions to install package 'Zebra.Printer.Card.SDK.2.15.2634'
Install failed. Rolling back...
Package 'Zebra.Printer.Card.SDK.2.15.2634' does not exist in project 'ZCDOTNETSC'
Package 'Zebra.Printer.Card.SDK.2.15.2634' does not exist in folder 'P:\Windmill\ZC300SC\packages'
Executing nuget actions took 48 ms
Could not install package 'Zebra.Printer.Card.SDK 2.15.2634'. You are trying to install this package into a project that targets 'native,Version=v0.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Time Elapsed: 00:00:00.1490121
========== Finished ==========
I have a C++ project supporting older Zebra card printers and I would like to add support for their current range but they have dropped C++ SDKs, so I would like to mix .NET with C++ if possible, so I can use the latest SDK.
Am I barking up the wrong tree and it's just not possible? I can only use C# with such a package?
I've checked several similar posts dating back to 2013 often suggesting editing XML in various project and packages files which I do not see on my set-up.
Thanks in advance for any pointers.
Related
I am trying to update one of my Xamarin.Forms apps that uses the deprecated Microsoft.WindowsAzure.Mobile.SQLStore pacakge with the new Microsoft.Azure.Mobile.Client.SQLiteStore package but I get the following error when I try to install the package in my Core pcl project:
Could not install package 'Microsoft.Azure.Mobile.Client.SQLiteStore 4.0.0'.
You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile78', but the package does not contain any assembly references or content files that are compatible with that framework.
For more information, contact the package author.
I tried to follow this documentation but they seem to forget to add the code sample, so I can't figure out exacly what they are doing. The deprecated Microsoft.WindowsAzure.Mobile.SQLStore package installed in a PCL library but the new Microsoft.Azure.Mobile.Client.SQLiteStore package doesn't or so it seems.
Any help would be appreciated.
It turns out that Microsoft.Azure.Mobile.Client.SQLiteStore 4.0.0 does not support PCL anymore but they moved to .NET Standard 1.4. PCL support stops at version 3.1.0
So if you are using PCL install v3.1.0. But before you install v3.1.0, make sure you manually remove the deprecated Microsoft.WindowsAzure.Mobile.SQLStore first.
Check out this issue for more details: https://github.com/Azure/azure-mobile-apps-net-client/issues/337
you can try and open the .csproj of your PCL and replace the Profile78 entry with a profile the NuGet package supports (probably Profile259 which includes almost everything but windows phone silverlight)
If your project won't compile after changing your profile (because there are missing type references e.g.) try picking a different profile the package supports.
If you're having multiple PCLs you might need to change the target profile of all of them.
Try Changing .Net profile to Profile 7 and then update.
Go To Cross Platforms Project Options->Build->General->.Net Portable
I am attempting to convert the Microsoft.Health C# class library that is installed as part of the HealthVault SDK, using instructions provided here. After following these instructions, I get the following error when attempting to load the project into Visual Studio 2013.
"The project is targeting frameworks hat are either not installed or
are included as part of future updates to Visual Studio. See
http://go.microsoft.com/fwlink/?LinkId=287985"
Visiting the link takes me to .NET SDKs and Downloads. Once there, I have no clue on what needs to be done.
I do realize that one will have to leverage the Portable Class Library Contrib project to fill in some missing bits, especially code related to System.Security. This, I will deal with later.
Any one run into a similar problem?
Maybe so late but for those who have the same problem.
I had the same error in a project which was working perfect before updating VS2013 and finally after 3 hours looking for the source of the error I found that the error is about TargetFrameworkProfile.
In my case I sloved it like so:
Right click in the unloaded project in your solution and click Edit.
Find the TargetFrameworkProfile tag and set it as below:
<TargetFrameworkProfile>Profile78</TargetFrameworkProfile>
At a guess, this is because you need to specify the TargetFrameworkVersion and TargetFrameworkProfile properties in the project file. Compare the .csproj you are trying to create to a newly created PCL project file, and make sure that everything that's not specific to your project matches.
I ran into the same issue and got it resolved by installing the latest Visual Studio Update
I have built a NuGet package for my Simple.OData.Client with support for Xamarin Android and iOS. This library uses Microsoft.Bcl.Async. Tests using Android and iOS simulator went OK, but when I install this new NuGet package into another project, it fails to compile Droid/Touch projects with the following message:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(720,2): error : Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'Microsoft.Threading.Tasks.Extensions, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Perhaps it doesn't exist in the Mono for Android profile?
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(720,2): error : File name: 'Microsoft.Threading.Tasks.Extensions.dll'
Of course there is no Microsoft.Bcl.Async pack (yet) for Mono platforms, on the other hand since the library tests pass on these platforms, I guess this more of a challenge to make Visual Studio happy rather than do some code modification.
Has anyone managed to use on Mono PCLs dependent on Microsoft.Bcl.Async?
Generally, if the code in your package depends on another NuGet package, you need to declare a package dependency so that anyone installing your package will get the one you depend on too. That should take care of issues like this.
However, in this case it is a lot more complicated. Since Microsoft.Bcl.Async doesn't support Mono platforms, you can't declare that package dependency (or if you did it would always fail to install). Unfortunately the license for Microsoft.Bcl.Async restricts it to "Windows platforms". I'm not a lawyer but I think that means you shouldn't distribute Microsoft.Threading.Tasks.Extensions.dll as part of your package. Finally, there's no official PCL support for Mono platforms yet, so if you do come up with a solution that works now it may change when official PCL support comes out.
If you want to attempt getting this to work, what you basically need to do is create your own DLLs with the same names as are in Microsoft.Bcl and Microsoft.Bcl.Async for use on Mono platforms. In those assemblies, put type forwards for the types that Mono already implements (which should probably be the types in the System.* DLLs), and create an implementation of your own for the other ones (the AsyncBridge source code is useful for this). This is what I did for one of my BUILD 2012 PCL demos. The code for that is here. AsyncFacades and AsyncBridge are the relevant projects.
For those stumbling into this issue when getting the Simple.oData.Client from nuget, just install the following packages from nuget:
Microsoft Bcl Async Portable
Microsoft Bcl Async
I believe I've found the problem.
Earlier I had the following line in Simple.OData.Client nuspec file:
<file src="Simple.OData.Client.Core\bin\Release\Microsoft.Threading.Tasks.Extensions.dll" target="lib\portable-net403+win8+sl5+wp8+MonoAndroid16+MonoTouch40\Microsoft.Threading.Tasks.Extensions.dll" />
This is not how it should be because Microsoft.Bcl.Async should have taken care of copying Tasks.Extensions.dll. I reported this to Microsoft and expected this to be fixed in the RTM version of Microsoft.Bcl.Async. Apparently it was not, so all NuGet packages dependent on Microsoft.Bcl.Async should still copy this file. Then it will work.
for who has the same issue I think you can downgrade
System.Threading.Tasks.Extensions 4.4.0
So I've been working on a game, and the sheer number of projects has become unmanageable. Enter NuGet.
I wanted to ensure my code would work on different devices, so I've been making these projects as Portable Class Libraries. I needed to use these on XBox, Windows, iOS, Android, and Silverlight. I created some custom custom SupportedFrameworks in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\Profile1\SupportedFrameworks
Specifically MonoAndroid and VSMonoTouch
I successfully turned one of these PCLs into a NuGet package, but when I try to add them to another PCL of the same profile I get this error:
Could not install package 'Framework.dll 1.0.0.0'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
The package folder was brought down and contains a folder named: portable-win+net40+MonoAndroid16+sl40+net10+wp+Xbox40 and indeed contains the requested dll. I am able to add this dll to my project manually, so I believe this may be a bug in NuGet. I investigated this online, and found the main fix was to update NuGet, because the newest version plays nicer with PCLs. I've updated, but to no avail.
Has anyone seen this before, or am I missing something obvious? Any help would be greatly appriated =)
Thanks,
Joshua
It looks like you are using ".NETFramework" for the identifier in the XML file you put in the Profile1 SupportedFrameworks folder. This was basically a hack to get iOS projects building on Windows, but with real support for that scenario you should change that identifier to MonoTouch. Then when you create the package it should use monotouch in place of net10 for the lib/portable-x+y+z folder.
Then, as #Deepak suggests, install the nightly build of NuGet. Then you should be able to install the NuGet package into your PCL project. If you do try this, please let me know whether it worked or not. :)
I am trying to deploy a Visual C++ application (developed with Microsoft Visual Studio 2008) using a Setup and Deployment Project. After installation, users on some target computers get the following error message after launching the application executable: “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.” Another user after installation could run the application properly. I cannot find the root cause of this problem, despite spending several hours on the Visual Studio help files and online forums (most postings date back to 2006). Does anyone at Stack Overflow have a suggestion? Thanks in advance. Additional details appear below.
The application uses FLTK 1.1.9 for a GUI library, as well as some Boost 1.39 libraries (regex, lexical_cast, date_time, math).
I made sure I am trying to deploy the release version (not the debug version) of the application. The Runtime library in the Code Generation settings is Multi-threaded DLL (/MD).
The dependency walker of myapp.exe lists the following DLLs: wsock32.dll, comctl32.dll, kernel32.dll, user32.dll, gdi32.dll, shell32.dll, ole32.dll, mvcp90.dll, msvcr90.dll.
In the Setup and Deployment Project, I add the following DLLs to the File System on Target Machine: fltkdlld.dll, and a folder named Microsoft.VC90.CRT with msvcm90.dll, msvcp90.dll, mcvcr90.dll and Microsoft.VC90.CRT.manifest.
The installation process on the target computers getting the error message requires having the .Net Framework 3.5 installed first.
Any suggestion? Thanks in advance!
Add the Visual C++ Redistributable to your Deployment project and be sure to run Setup.exe instead of the MSI when installing. This will invoke the VCRedist bootstrapper to ensure your PC has those pieces before installing your app.
Dependency Walker only shows static (link time) dependencies - it cannot possibly know about dynamic dependencies such as COM objects.
I had a similar problem after the ATL security updates last year. My app needed a later version of the C++ runtime libraries than the deployment project included.
Try running Windows Update on the target machines after installation, or download and install the latest (28 July 2009) C++ redistributable package directly.
http://support.microsoft.com/?kbid=973551
That solved the problem for me. I haven't fixed the deployment project yet though.