For my UI system, which is similar to WPF but written cross plattform with OpenGL, i need to embed the xml files into the DLL which are used to layout the user controls. The problem is: By default MonoTouch does not support embedding any file into a dll and afaik there is only one solution which solves this: Embed the xml into a *.cs file and compile it.
Now, this is a task which doesn't make any fun if you do it per hand each time, so the question is how is the best way to achieve this for both, Visual Studio and MonoDevelop?
MonoTouch does not compile C# code, it uses the smcs compiler. That's the same compiler being used for Mono for Android and, originally, for Moonlight.
That smcs compiler is able to embed files into assemblies, it's doing so the BCL (e.g. globalization files for mscorlib.dll) and that was an important requirement for XAML (in Moonlight).
Related
I'm learning F# and I'm just trying to build Animate a pendulum program.
Here's the code:
https://rosettacode.org/wiki/Animate_a_pendulum#F.23
As far as I understand, VS 2019 doesn't support WinForms in F# (maybe, I'm wrong), so I have error messages, trying to copy/paste that code:
What should I do?
Thanks a lot !
If you're looking to use Winforms on .NET core, you'll need to do the following in your project:
Open the project file (double-click on the node in Visual Studio)
Change the Sdk to Microsoft.NET.Sdk.WindowsDesktop
Ensure you have this OutputType: <OutputType>WinExe</OutputType>
Add the following property to the top-level PropertyGroup: <UseWindowsForms>true</UseWindowsForms>
There won't be a visual designer to use, but you should have access to the APIs.
Unfortunately, there is no Winforms designer in Visual Studio 2019 for F# projects of any type, and Winforms can only be easily accessed (as far as I know) in .Net Framework (NOT .NET Core) projects they can be accessed as per #Phillip Carter's answer.
However you can still make Winforms programs easily by manually adding the references to your .NET Framework project, or (more easily) by manually compiling with the F# compiler, fsc.
The Fast Way
The easiest way to do this is simply compile the source code with the F# compiler from a single source file with fsc.exe. The F# compiler will automatically resolve dependencies for things like System.Windows.Forms and a lot of other commonly used namespaces. You can also provide lots of compiler directives for requiring other resources as well.
Example using VSCode, with various extensions:
Another Way
Start a new F# console .NET Framework project (don't pick .NET Core).
Right click on "References" in the Solution Explorer and click "Add Reference..."
Under assemblies, look for "System.Windows.Forms," select it...
And also select "System.Drawing" and then hit OK
Now you have access to both of those namespaces.
Before you run the project in Visual Studio, you should replace
[<STAThread>]
Application.Run( new PendulumForm( Visible=true ) )
with
[<STAThread;EntryPoint>]
let main _ =
Application.Run( new PendulumForm( Visible=true ) )
0
This way you (and VS) know where main actually is. It's not necessary for this small of a program to actually run it, but as your projects get larger VS will complain more about where things are located in your project.
I have a problem with the MWArray.dll which is the original dll library from mathworks compiled from Matlab. This dll works under visual studio but not under unity. The goal was to compile under matlab a simple function mycos which calculates a cosinus and uses it under unity with the second dll MWArray mathworks library.
I made a test under Visual Studio and it works well. I have no problem to read the dll and make a call to the mycos.dll class. I made a typical c# project with two references on MWArray and mycos.
But when I try under unity, by putting the two dll under a plugins folder and configure unity 2018 on .NET 4.0 because the dll are compiled with the .NET framework 4.0.
Unity can read the dll but when running I get an error:
NotImplementedException: The requested feature is not implemented.
System.Security.Principal.WindowsIdentity.GetCurrent (Boolean ifImpersonating)
(at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Security.Principal/WindowsIdentity.cs:166)
If I want to use matlab for a research project which was coded in matlab with advanced high level math functions which going to be difficult to recode under unity with c#. So the easy way is to use compiled package from matlab compiler. So is there someone who did this already?
The solution consists in NOT using MWArray.dll in Unity project because of incompatibility with Mono. Create a Visual Studio project (when creating new select the type "console applicatiion"), it MUST be separated from unity project directory, and use it as an application server; in fact in that app you can use MWArray.dll, remember that you have to configure your project configuration to x64!!! In the Unity project create a client app to communicate with the other server project.
Let's say I've got an existing .NET assembly built in Visual Studio 2010, which is consumed in some other Winforms product. It has no third-party dependencies.
I want to reuse that library directly in a MonoTouch solution.
As it stands, to be able to add a reference to my library from within my MonoTouch UI project, I have to create a new csproj file and create links to all of the source files within it.
This works but is a maintenance burden. There must be a better way?
Thanks in advance.
As of today you need to rebuild your assemblies. That's because they'll be linked to monotouch BCL (e.g. a different mscorlib.dll) which a superset of the base class libraries (BCL) shipped with Silverlight.
Hopefully newer release of MonoTouch (and Mono, Mono for Android...) will support the new "portable library" which would make it easier to share compiled binaries across frameworks.
http://blogs.msdn.com/b/bclteam/archive/2011/01/19/announcing-portable-library-tools-ctp-justin-van-patten.aspx
Believe it or not, you actually can reference a .dll lib built in VS.NET as long as your shared assembly is not referencing any other assemblies that would make it incompatible with monotouch. I currently am doing this on our project. The referenced .dll only has dependencies on System and System.Core and its basically just a set of POCO's. I'm sure someone with better knowledge can tell you exactly what it would take to make the .dll incompatible. Even using an incompatible API call within System or System.Core could break it per poupou's answer but if you keep your shared .dll dead simple it should work.
My background is c#, .net, and Visual Studio.
I've been trying to get to grips with Cocoa development, but am finding it hard to find information about certain things, maybe because I'm coming in from a Visual Studio perspective.
A few questions:
What's the difference between a "Framework" project, and a "Library" project in XCode?
What are the consequences of choosing "dynamic" or "static" for your project when starting a new XCode project. Can this be changed later on? does it affect the contents of the project?
Does XCode have the concept of a "solution" with various projects like Visual Studio? If so, how do you reference projects with each other which are in the same solution in XCode?
Is it even right to approach a Cocoa project in the same way as a .net one. For example, if I was going to build a simple image manipulation app, I'd start with the core library, which could be referenced in a winforms, silverlight, or an MVC frontend app. How does that organisation work in XCode?
A Framework project builds a Framework, and a Library projects builds a Library. A Framework (.framework) is the means by which a library and its associated header files are bundled together in one package (similar to the way an executable and its sundry files are bundled together into a .app package). If you're building a library which you intend to use in multiple Cocoa projects, or distribute to other developers for that purpose, a Framework is probably the most convenient way to do so.
A static library (.a) is analogous to a .lib file in Windows. It's compiled code which you can link into your executable. A dynamic library (.dylib) is analogous to a .dll in Windows. It's compiled code which can be dynamically loaded by your executable. You can change the output from one to the other after you create it (see the Mach-O Type field under Linking in the Build tab of Project Info. However, there are probably other settings which would vary between the two. My advice would be to decide which you want to make, make the project for that, and don't change it.
Yes, you can build multiple things from an Xcode Project. An Xcode project is exactly analogous to a Visual Studio Solution. What Visual Studio calls Projects, Xcode calls Targets. So an Xcode project can have multiple targets. Say, one for a Framework, one for an application that uses that framework, one for a suite of unit tests, etc. Make yourself an Xcode project, and right click Targets->Add->New Target, and you can play around with it. Each Target has its own build settings, files, etc.
My background is more the MFC/C++ side of the Visual Studio house than the .NET/C# one, but to my knowledge, what you describe is possible, even desirable, in Xcode, sure. My projects have thus far never been large enough, nor the code amongst them common enough, to bother having a separate library for core functionality, but there's no reason you couldn't do that.
I have a communication library built on top of Qt and Google Protocol Buffers. It's currently being built with MinGW/GCC on Windows. My goal is to use the same library in C# on .NET, with the help of a thin wrapper on top using C++/CLI (bridging the unmanaged code with managed code).
I tried using the MinGW produced DLL directly in my C++/CLI project, but I keep getting linker errors (cant remember the error codes right now, but something about missing tokens and functions/signatures).
First question is: Should I be able to use the MinGW-produced DLL with the Visual Studio compiler/linker? Or do I need to compile the library again, using only VS compiler for all projects?
If I should be able to use the MinGW-produced DLL directly, how do I reference it in Visual Studio 2010? In project settings it seems to look for *.lib files, but I can't find any .lib files in the output of MinGW/GCC. It does produce *.a files, but it seems like Visual Studio don't handle this kind of file..
I should also mention that both Qt and protobuf are also compiled with MinGW. But I can of course recompile all the parts in VS 2010 if necessary.. Would have been nice to save the recompile time though, since our buildserver already has a working setup using MinGW.
The easiest way to use it would be by recompiling it with Visual Studio. This is when I am assuming C++ types and classes used in the interface you intend to use.
In case you have a C interface to this library you could dynamically load the library via LoadLibrary and use GetProcAddress to access those functions.
However it depends completly on the way how you intend to use the library.