I'm working with compiling the google apps API and I haven't seen it where I'm missing.
.net and windows 8/8.1 are both listed but nothing else. I'm running VS 2013 on a Windows 7 computer.
Because of this, when I go into references to the project, I'm missing all of the original microsoft references (even if I go to add them, there's nothing to select from).
For example, the error I'm getting is: Warning 2 The primary reference "System.IO", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETPortable,Version=v4.0,Profile=Profile5". To resolve this problem, either remove the reference "System.IO" or retarget your application to a framework version which contains "System.IO". Google.Apis.Admin.Directory.directory_v1
I'm not sure why that and all the other microsoft API's are not showing up when I go to select them (or not allowing me to compile). I assume it's because of the .netportable and the fact I'm not on a Windows 8.x computer.
Anyone know how to change the target? I don't see anyway of doing that.
What you have there is a Portable Class Library. It's lacking many namespaces and functions that are native to Windows only; basically, a PCL is reduced to the minimum feature set of .NET that can run on all target platforms.
For many missing namespaces there are replacement PCLs; if none is available, you can define interfaces in the PCL (and implement them in platform-specific code) that serve as a "bridge" between the PCL and e.g. the System.IO namespace on Win32.
Simple example: You define IFileIO with WriteFile(...) and ReadFile(...) in the PCL; then every project that uses the PCL (ex.: WindowsIO Windows) has a class that implements IFileIO and executes the System.IO calls within the respective functions.
Then you combine the Windows-specific implementation with the PCL interface; imagine you have a ImageConverter class that reads, modifies and writes images. Its constructor accepts an IFileIO, where you can pass a WindowsIO instance (or Win8IO, or AndroidIO, or ...). The ImageConverter only uses the interface and doesn't care about the implementation.
Related
I have a .NET 6.0 C# class library project that contains platform-independent code (let's call this BusinessLogic). In my same solution, I would like to create a project for a WinUI 3 app that references this class library (let's call this WindowsApp). I would also like to create a class library specific to the Windows platform (so I can access the Windows.Storage namespace from within that class library, for example... let's call this WindowsOS).
I get an error when attempting to set this up. I have tried two techniques:
First technique
Create a .NET 6.0 C# class library WindowsOS.
In WindowsOS project, add reference to BusinessLogic. No problem.
In WindowsOS project, install NuGet packages Microsoft.Windows.SDK.BuildTools and Microsoft.WindowsAppSDK. This gives me an error about numeric comparisons on the target platform, similar to the one described in this GitHub issue. Afterwards, the project becomes unloadable in Visual Studio.
Second technique
Create a Class Library (Universal Windows) project WindowsOS.
In WindowsOS project, add reference to BusinessLogic. This gives me an error immediately, simply refusing to allow the reference to be added.
I suspect there appears to be some compatibility issue going on. I reviewed the Microsoft docs on .NET Standard versions, as well as this helpful StackOverflow question about .NET Core vs .NET Standard class libraries, and from what I can tell UWP may not be capable of referencing .NET class libraries.
My end goal is to create a WinUI 3 desktop app that references these cross-platform class libraries. My common code is contained in these libraries, and I may make an Android app or other platform app in a separate project that also references these same cross-platform class libraries. How do I do this?
EDIT: Here is a screenshot of the error from technique #1:
I figured out the answer. In the Visual Studio project properties (screenshot below), there is a Target OS property. That property defaults to (None).
Given the names of the projects in the question, set the property accordingly:
Set the property value to Windows in the WindowsOS project. This will give access to Windows-platform specific namespaces (such as Windows.Storage). WindowsOS can still have a project reference to BusinessLogic (and any .NET 6.0 C# library) as before.
No change necessary to the BusinessLogic project properties.
The WindowsApp (WinUI 3) project also requires no changes, and can reference BOTH the WindowsOS project (which now has a Target OS of Windows) AND the BusinessLogic project (which still has a Target OS property of (None).
Something to keep in mind: the WindowsApp project and the WindowsOS project will now both have Target OS version and Supported OS version properties. If you set these to different values in each project, you will get compiler warnings about a potential conflict (a user could install the app with a lower version of Windows, but that app then references the library which may require a higher version of Windows than the user has, for example). This does not matter if you are only using APIs supported in BOTH versions of Windows, but to be safe make sure these are consistent between your projects.
I try to create a really simple app containing
Windows Version
Mac Version
Portable Class Library
I would like to put the code (as much as possible) into the Portable Class Library.
Now i simply want to check if a file exists using System.IO.File.Exists() but the File object is not available. I tryed to target different plattforms but i cant get it to work.
What #hvaughan3 said is correct in that the System.IO.File is not available from your PCL and it needs to be implemented within each platform and injected into your PCL. That said the good news is that like many of these common requirements there already is a plugin to do that so you don't need to do it yourself.
Have a look at the following blog post that describes how to use the PCLStorage plugin within your PCL project.
System.IO.File is not available in the PCL code. You will need to implement in platform specific code. You will also need to verify that it exists for each platform. I know it does for Android and iOS, have never tried using it on Mac and Windows. Although from Xamarin's docs it looks like at least Mac does have System.IO.File.
Once you have methods in each platform project, you can reference the platform specific method from your PCL code using Xamarin's Dependency Service.
Hi there I am new to the windows phone development and I am trying to build a data driven application in which I have Created my BLL and EL and DAL ,which are all of windows phone class library type project.
I have also an extra project of type class library in my solution in which I have added the Reference to "MyGeneration.dOOdads.dll" file .
Now I want this project to be referenced in the windows phone app project.But when I try to add a reference ,The VS 2010 says...."Unable to add the selected project refernce.The project reference must be another silver light for windows phone project that is the same or the lower version ".
.
.
.
Kindly help me in this scenario. Thanks
That can't and won't work. The phone runtime only has access to a timy subset (well, sort-of) of the full .NET libraries, so any non-phone-7 library is extremely unlikely to operate at all. To stop this surprising people, only libraries built against that runtime are allowed to be referenced.
If possible, create a new project with the same c# files, targeting the phone 7 framework. Now reference this project. It is quite likely that some bits will fail to compile (demonstrating the fact that it also wouldn't have run), which can be rectified in a number if ways (#if blocks, alternative .cs files, etc).
You might also have some luck by making the existing project a "portable class library" - this, however, is the most restrictive subset of all the common frameworks, and is even less likely to still compile (without changes).
Using the Portable Class Library project, you can build portable assemblies that work without modification on the .NET Framework, Silverlight, Windows Phone 7, or Xbox 360 platforms.
(from MSDN)
i'm building a Service-Client application using Silverlight and WCF, i have a Model project (which contains POCOs) on the Server side, and i wanted to share those same entities to the Silverlight-Client Application, and i thought, hey! I can change the Model project to be a Silverlight class library, and it should work just fine.
I did the change and now, i'm able to add the references however it is getting the exclamation mark like when the reference is not resolved... and if you take a look at the properties the value of "Resolved" is set to "False", this is causing the following Code Analysis Errors:
CA0058
[CA0001][2]
Please note:
this is not the typical question about referencing a Typical Class Library from a Silverlight project (i Know that can't be done), but the other way arround.
It should work fine (unlike what Wayne says, you can actually reference Silverlight assemblies from projects that target the full .NET Framework). However, you may have references in this project that the full .NET Framework can't load (you generally need to keep your references to the most base types). You've got two alternative options.
Create two class library projects (one targeting Silverlight, the other the .NET Framework), and share the files between them, as I discuss in this article: http://www.silverlightshow.net/items/Building-a-Silverlight-Line-Of-Business-Application-Part-3.aspx
Try out the Portable Library Tools (currently in beta): http://blogs.msdn.com/b/sburke/archive/2011/01/23/3-screen-coding-is-here-portable-library-tools-allow-you-to-target-multiple-net-platforms-with-one-binary.aspx
Hope this helps...
Chris Anderson
For the same reason you can't reference a CLR assembly from a Silverlight project, you can't reference a Silverlight assembly from a CLR project -- they're different runtimes.
We wrote a small Windows class library that implements extension methods for some standard types (strings initially). I placed this in a library so that any of our projects would be able to make use of it by simply referencing it and adding using XXX.Extensions.
A problem came up when we wanted to use some of these methods in Silverlight. Although all the code was compatible, a Windows library can't be referenced in Silverlight so we created a Silverlight library that had links to the same class files and put compiler directives into the classes to allow different using declarations and namespaces. This worked fine until today when I added a new class to the Windows extensions library and realised that I would have to remember to link the class into the Silverlight library too.
This isn't ideal and I wondered if anyone might have ideas for a better way of sharing extension methods and other helper code between Windows and Silverlight projects.
You cannot set a reference from a Silverlight assembly to a regular .NET assembly but you can do so the other way round.
So create a shared Silverlight assembly and add your code to that assembly. Now you can set a reference fro both your regular .NET and you other Silverlight assembly to the shared Silverlight assembly.
The restriction is that you can only put code in there that would work on both the .NET and Silverlight CLR but that is no different from sharing code.
Since this question has been answered, there is a new solution from Microsoft, Portable Class Libraries. Here is the blog post where they announced it.
I'm just about to start playing round with them for sharing code between silverlight and some server side code I'm writing, so can't add too much past the links at the moment.
Silverlight runtime is different from the normal .NET runtime. So you need to do tricks at the project level to share code between multiple platforms.
Here's how I've done this for Autofac IoC container.
With this approach you do not have to create different projects for each platform being targeted.
PS: there is also a Project Linker tool from the Composite WPF that allows to link Silverlight and WPF projects (creates multiple projects). But it does look messy.
there is a similar problem with XNA projects. Since you can target several different platforms, you're required to have different projects. The reason for this is because the base class libraries that the project references are platform specific, so you can't have just one project.
If you're curious, you can get a bit of insight from this blog:
To recompile the source for another
platform, you need another project.
The reason for this is because the
projects need to reference different
assemblies for both the XNA Framework
and the underlying .NET Framework
(Xbox 360 and Zune use the .NET
Compact Framework), and C# projects
don't provide support for referencing
different assemblies for different
platforms.
Try this http://buildassilverlight.codeplex.com/
I had some dependency issues when referencing to a Silveright class library in .Net.
An alternative way when using Visual Studio 2010 and WCF RIA 1.0:
Create a normal .Net library assembly.
Create a Silverlight class library. In the configuration of the assembly specifiy the first .NET library as the "WCF RIA Service link"
Put your code in the .NET library as "ClassName.shared.cs" files.
WCF RIA will handle copying the file to the Silverlight assembly.