I created a C# class library using visual studio and it works well in visual studio, and when trying to execute it in mono develop I get error the library code:
namespace ClassLibrary2
{
public class Class2
{
public static void dosomething() {Console.WriteLine("dfss"); }
}
}
the code in mono develop:
namespace cons
{
class MainClass
{
public static void Main (string[] args)
{
ClassLibrary2.Class2.dosomething();
}
}
}
the error
What target framework (2.0, 3.5, 4.0) did you specify in VS?? It seems that your mono develop uses different (lower) version.
You need to check that your .Net Framework versions are the same. You will have chosen a framework in VS that is different to that which mono develop is trying to use. This is a very common cause of this error.
The missing assembly is ClassLibrary2 and your code only deals with ClassLibrary1.
Maybe you could add the registry key to enable a more verbose logging.
Related
I'm trying to import a VERY SIMPLE custom C# class into Python using pythonnet. I've never used C# or VS, so It's probably some stupid mistake I'm doing.
I have got a solid C# code base (not written by me) that I want to drive using Python.
I have this C# class:
using System;
public class MyClass
{
string text;
public MyClass(string text)
{
this.text = text;
}
public void Write()
{
Console.WriteLine(text);
}
}
In VS 2017, I've created a .NET Core Class Library project. It compiles fine and creates a MyClass.dll file.
Then I'm trying to import it in Python:
import sys
sys.path.append(r"C:\Users\myuser\source\repos\hello\MyClass\bin\Debug\netcoreapp2.1")
import clr
clr.FindAssembly(r"MyClass")
clr.AddReference('MyClass')
import MyClass
But I always get a "ModuleNotFoundError: No module named 'MyClass'" error.
Turns out I was compiling the DLL with .NET Core. Changing to .NET Framekwork 4.5 solved the problem.
I wish the error messages were more helpful.
I'm trying to get .Net Framework and NetStandard assemblies to communicate with each other (to learn what is possible). I currently have four projects, two Framework 4.5.2 projects and two NetStandard1.2 projects:
Framework452.Library
NetStandard12.CentralLibrary
NetStandard12.BaseLibrary
Framework452.Tests
The referencing structure is:
Framework452.Tests references NetStandard12.CentralLibrary: working by adding the NetStandard.Library nuget package to Framework452.Tests.
NetStandard12.CentralLibrary references NetStandard12.BaseLibrary: working without modification.
NetStandard12.CentralLibrary references Framework452.Library: Not working, even when Framework452.Library has the NetStandard.Library nuget package installed.
Can NetStandard projects reference Framework projects? If so, what do I need to do to get them to communicate? At the moment I can add the reference, but it is not visible to the code.
Update
I recreated the solution and added the code below, which when I try to compile gives the following error from the Framework452.Tests project:
Error CS0006: Metadata file
'~\TryNETStandard\NetStandard12.CentralLibrary\bin\Debug\netstandard1.2\NetStandard12.CentralLibrary.dll'
could not be found.
namespace Framework452.Library
{
public class Returner452 {
public static bool ReturnTrue() { return true; }
}
}
using Xunit;
namespace Framework452.Tests
{
public class Class1 {
[Fact]
public void FrameworkTest() {
Assert.True(NetStandard12.CentralLibrary.Class1.Return452());
}
[Fact]
public void NetStandardTest() {
Assert.True(NetStandard12.CentralLibrary.Class1.Return12());
}
}
}
namespace NetStandard12.BaseLibrary
{
public class Returner12 {
public static bool ReturnTrue() { return true; }
}
}
using Framework452.Library;
using NetStandard12.BaseLibrary;
namespace NetStandard12.CentralLibrary
{
public class Class1
{
public static bool Return452() { return Returner452.ReturnTrue(); }
public static bool Return12() { return Returner12.ReturnTrue(); }
}
}
According to this page https://learn.microsoft.com/en-us/dotnet/standard/net-standard#net-platforms-support you should be able to achieve your purpose because .NET Standard 1.2 support .NET Framework 4.5.1 (UPDATE: This statement is not 100% correct. Please see the Update section below.)
I tried to set up a solution in VS 2017 and set the references as you described. Here is the result.
and this is the Class1.cs in NetStandard12.CentralLibrary
The code compiles fine without any errors.
Note: your code may fail if the Framework452.Library uses an API that is not supported by .NET Standard 1.2 (e.g Winforms, Win32 API or any Microsoft proprietary library that does not make sense for cross platform).
I recommend this youtube playlist on the .NET standard introduction from one of the MSFT https://www.youtube.com/watch?v=YI4MurjfMn8&list=PLRAdsfhKI4OWx321A_pr-7HhRNk7wOLLY
In .NET Standard - Checking Compatibilty , he recommended tools to help you find out what API is not supported in the .NET Standard.
Thing will become easier with .NET Standard 2.0 and 'compat shim'
UPDATE:
After trying again with more data provided by the question, it's true that a library targeting (depends) .NET Standard could not depend on a library that target .NET Framework. For some strange reason, the compiler allows me to compile the example that I gave above. This could be a bug in tooling.
After a little more research, I found a good example demonstrate the relationship between NetStandard and NetFramework: How .NET Standard relates to .NET Platform.
The graph here show the dependencies
According to the graph, there is no way a library that depends on .NET Standard could see/use the .NET framework implementation.
When .NET Standard 2 is released, this may change a little bit and you could reference .NET Framework via Compatibility Shim. See this video for more in-depth explanation https://youtu.be/vg6nR7hS2lI?list=PLRAdsfhKI4OWx321A_pr-7HhRNk7wOLLY&t=169
No, .NET Standard projects cannot reference framework projects.
.NET Standard projects need to be usable across platforms, forcing a dependency on the .NET framework by referencing an assembly targeting it makes this impossible.
Note that with some of the magic Microsoft is doing with .NET Standard 2.0 this is less true but the overall idea still stands.
I'm developing a library for use with WPF and Windows 10. I'm running into issues getting it to compile on the latter. Here is some of the code:
project.json
{
"frameworks": {
"net46": {
"frameworkAssemblies": {
"WindowsBase": "4.0.0.0"
}
},
"netcore50": {
"dependencies": {
"Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0"
}
}
}
}
Dependency.cs
using System;
using System.Collections.Generic;
#if NET46
using System.Windows; // .NET Framework 4.6
#elif NETCORE50
using Windows.UI.Xaml; // Windows 10 apps
#endif
public static class Dependency
{
public static DependencyProperty Register<T, TOwner>(string name, PropertyChangedCallback<T, TOwner> callback)
where TOwner : DependencyObject
{
// Code here....
}
}
While this compiles fine for net46 (which is the traditional .NET Framework), I'm having trouble getting it to work for netcore50 (which can be used by Windows 10 apps). For some reason, it looks like types like DependencyProperty or DependencyObject are not included in that configuration.
Is there a netcore50-compatible NuGet package I can install that contains these types, so I can use them from my library?
Thanks for helping.
EDIT: I just typed in DependencyProperty in VS and hit F12. It appears that the type lives in the Windows.Foundation.UniversalApiContract assembly, but there's no such package on NuGet.
Finally solved the problem on my own! (If you're looking for a quick answer, you may want to scroll down.)
I remembered by chance that the .NET Core GitHub repo had a bunch of WinRT-specific libraries, like System.Runtime.WindowsRuntime. So, I headed over there to see how they did it.
It appears they use some kind of internally-hosted "targeting pack", which contains a single Windows.winmd file (which holds all the types in the Windows Runtime), to achieve this affect. Unfortunately, the package is hosted on a private NuGet feed meant only for the .NET Core team, so I can't use it.
I've opened an issue about this on the CoreFX repo here, so I can petition Microsoft for an official solution to this problem. In the meantime, I've taken matters into my own hands. I've found all the different versions of Windows.winmd on my laptop, and uploaded them as NuGet packages. Here they are:
Target.Windows
Target.WindowsPhone
Target.WindowsRuntime
You can use them like this:
"frameworks": {
".NETPortable,Version=v4.5,Profile=Profile32": {
"dependencies": {
"Target.WindowsRuntime": "8.1.2"
}
}
}
After that, you'll be able to write something like this:
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
public class MyApp : Application
{
public MyApp()
{
var button = new Button();
button.Content = "Hello, world!";
}
}
and it'll just work.
With .NET Core 3 and up (now in preview) there is a package you can install that includes most WinRT classes Microsoft.Windows.SDK.Contracts
WPF Isn't compatible with .net Core nor are W10 Universal Apps, to my knowledge only Console apps and web apps are currently compatible with .net core, you should be able to still use the the new code base with the new project system but you will need to remove .net core from your configuration in order to compile
if you want to use .net core with linux with a desktop app you will simply have to wait, or use a compatible windowed app framework ( if any are available yet), you should be able to use a cross platform framework base around html/js such as Electron or Cordova ( not sure on this one on whether there is a desktop app framework with Cordova)
I apologise for this - it's an idiot question and I hate myself for asking it, but I can't figure out a reason for this behaviour.
I have a namespace which contains a mixture of static and non-static classes.
namespace MyNameSpace.UI.Helpers
{
public static class OrderHelper
{ // static methods
}
}
namespace MyNameSpace.UI.Helpers
{
public class CountToCampaignConverter : IMultiValueConverter
{ // non-static methods
}
}
These being helper classes, they're used throughout the application. In this class:
using MyNameSpace.UI.Helpers;
namespace MyNameSpace.UI.ViewModels
{
public class QuickCountViewModel : BaseViewModel
{
private void BuildOrderExclusionsOnCount()
{
CurrentAvailability.OrderExclusions = CountHelper.BuildOrderExclusionAsCsv(ordersToExclude);
}
}
}
However in this class:
using MyNameSpace.UI.Helpers;
namespace MyNameSpace.Service.Services
{
public class FulfillJobs : BaseService
{ // stuff
}
}
When I try to use my helpler classes, I've got access to the non-static ones, but none of the static ones.
I can't see any naming clash here - if that were the problem, surely I wouldn't be able to get the non-static ones either?
So where else can I look to resolve the issue?
This is an old post, but no fix was discovered and this issue just happened to me. Here's my particular scenario and the resolution.
I had a Visual Studio 2019 C# solution with two projects: a .NET Standard 2.0 class library and a .NET Core 3.1 console app that used the library. Everything worked fine until I changed the library from .NET Standard 2.0 to 2.1. Afterward, new static items (classes, properties, methods) defined in the library would not be recognized in the app or Visual Studio. If I reset the library back to .NET Standard 2.0 then the static items became visible, but that was not a viable solution for me.
To solve the problem, I set the library's target framework back to .NET Standard 2.1. Then I opened the app project's Reference Manager (Solution Explorer > App Project > Dependencies (right click) > Add Project Reference). I cleared the existing reference to the library and clicked OK. Then I repeated the process, but restored the reference to the library. Suddenly, the app and Visual Studio recognized all the new static items in the library.
The reason is because in the second sample, the class is in a different namespaceMyNameSpace.Service.Services.
If you add a "using" for the namespace MyNameSpace.UI.Helpers in your file, it will be visible.
You can also reference your class as UI.OrderHelper from your services, since both share the root "MyNamespace".
I have been developing a managed extensibility framework application for the last several months using the community preview. I have been using the GetExportedValues() method and the PartCreationPolicy(CreationPolicy.NonShared) to fake a class factory (since only the silverlight version supports a factory). This was working great until I upgraded the project to use .net 4.0. There is no error, it just doesn't work.
So why did this code stop working? The code follows:
The factory method:
public static IEnumerable<DataActionBase> GetActionsFromDirectory(string PluginsFolder)
{
IEnumerable<DataActionBase> result = null;
var catalog = new DirectoryCatalog(PluginsFolder);
var container = new CompositionContainer(catalog: catalog);
result = container.GetExportedValues<DataActionBase>();
return result;
}
Example Export Class:
[Export(typeof(DataActionBase))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class AnAction : DataActionBase
{
....
}
Have you recompiled your extensions against .NET 4.0? If the extensions reference the codeplex preview version of MEF, then the .NET 4.0 MEF won't pick them up. This is because the export attribute would be coming from an assembly with a different strong name, which .NET 4.0 MEF knows nothing about.