I am creating a .net library in Visual Studio 2015 with the following aims:-
Support for .net 2, 3.5, 4 and 4.5+
PCL Support (.net 4.5+)
No extra dependencies apart from Json.net
Ideally the .net 4.5+ version of the library would make use of async, and include methods that return Task etc
Now there seems to be many different ways of supporting what I want to do, especially with the Visual Studio 2015/project.json release but what is a good approach starting from scratch today?
My library is relatively simple, so as much as I want to re-use code I don't want to compromise the .net 4.5 version.
What would be a sensible project structure, that would mean I could take advantage of the latest .net framework, but still build in support for older frameworks.
With Beta8 of the WebDev tooling you are able to also target net2, net35, net40, net45, ...
Your library differences you might use #ifdef flags in your code to hide certain methods in certain builds.
Related
I'm getting into Unity, and wondering if I can use F# instead of C#, simply because I prefer the syntax. I'm guessing not, since the environment it runs on is very different, but maybe there's something that will cross-compile code or something else I'm not thinking of.
I can't help but get the impression that the other answers were written by people who do not really know what they are talking about.
This is what you need to do to use F# in a Unity project:
Create an F# project that compiles into a dll. Have it build into the assets folder of a Unity project.
Add references to UnityEngine.dll and/or UnityEditor.dll. Change the reference properties so the dlls aren't copied to the build folder.
Of course you can't create new F# classes from within the Unity editor this way, but you can assign the ones you wrote in F#.
Currently you need to enable the (experimental) support for .NET-version 4.5. Alternatively you can download an older version of the FSharp.Core.dll that supports .NET 3.5. (see here).
I can't guarantee that you won't run into trouble because of compatibility issues with the FSharp.Core.dll, but that's just a guess since I haven't tested it myself.
I had success doing this sometime back by following this Github project: https://github.com/eriksvedang/FSharp-Unity, which I believe is roughly the same as Lars Kokemohr's answer above. I haven't tested it in more recent versions of Unity/Mono however.
Yes you can use F# as first class language as C# in unity.
Here is an article about it link
an excellent blog for One who want to use F# in unity
if you want to use F# as second class which I recommend.
let me show how to do it.
Usually what I do is to create Game Domain in F# in .net standard
2.0 library project build it.
Make unity API Compatibility level .net standard 2.0 then
Import library project dll in asset/plugins in Unity
Here is an explanation on how to do it automatically after each build : link
You will get this error, here is the solution
Having said that I recommend not to do any serious work in unity with F# because you won't be able to cross compile to other platforms.
Unity uses IL2cpp and it don't work with F#.
In simple words unity don't support F# and if you are having issues like bugs in Il2cpp unity will not fix it because they don't support F#
There is no easy way to do this but if you REALLY want to make it happen I believe you could use something like fs2cs:
https://github.com/hsharpsoftware/fs2cs
In theory you could write a script that calls fs2cs on all of your Unity C# files. Integrating this with Unity itself would be the more challenging part, but in theory you can trigger fs2cs transpilation on save of your file and Unity can use the transpiled C# file.
Only Boo, C#, and UnityScript are officially supported!
I have a Data Access Layer solution built in Visual Studio 2010. It uses Entity Data Model (.edmx files) to create object models of the data.
It is built with .Net 3.5 framework so I assume this is also version 3.5 of Entity Framework?
We use a number of TVFs to return datasets and unfortunately EF 3.5 does not provide access to TVFs. So we have has to build tsql views that call those TVFs.
Is it possible to upgrade this solution to EF 6 and use TVFs? What are the steps involved?
Microsoft has release a guide to do. You find it here:
https://msdn.microsoft.com/en-us/data/upgradeef6.aspx
It involves getting the latest assemblies and do some modifications in order to run. It seems upgrading from an older version is a little harder than from a new version.
I have a requirement to create a framework for a shared set of common utilities that we plan to use in multiple iOS projects in our organization. The utility classes are written in swift and the framework needs to support projects in iOS 7 and above. I'm using Xcode 6.1.1.
I tried creating both a 'Cocoa Touch Framework' and a 'Cocoa Touch Static Library' and can't seem to get it working for iOS 7 builds.
With 'Cocoa Touch Framework', I get a warning that 'Embedded dylibs/frameworks only run on iOS 8 or later' and though I can get it to run, it fails during the iTunesconnect step with an error that the project's deployment target must not be less than 8.0 (mine is 7.0).
I tried with 'Cocoa Touch Static Library' as well using the steps given in http://www.raywenderlich.com/65964/create-a-framework-for-ios, but it just does not build with swift files. When I remove all swift files and add Obj-C files, it works properly.
Any help is greatly appreciated. How do I create a framework for a swift project with iOS 7+ support?
Thanks
Unfortunately, you cannot. It's one of the more disappointing factors about Swift.
As shown in the documentation, you cannot make a static framework/library with swift and dynamic libraries are only supported in iOS 8+.
The only option I recommend is that you develop an Objective-C static framework for iOS 7 and then begin to use swift when you wish to drop iOS 7 support. It's not the most ideal situation, but because you are able to have mixed languages in a dynamic framework, it means you won't have to waste time rewriting code (unless, of course, you want to).
Apple not supporting pure Swift frameworks before iOS 8 is somewhat hurting Swift adoption rate.
I'm not advocating the following solution as best practice. Honestly, it's a very flawed hack. We have a large pure Swift framework that does most of the heavy lifting for things here at work. And, we needed that framework in a product that ran on iOS 7.1+.
Here is the hack - Directory hierarchy is important. In an ideal situation, the project and the framework are siblings in the directory tree. Create a group in the project. In Finder, shift/command select all of the source files from the framework, and drop them into the newly created group. Make sure not to copy the files. Your telling Xcode to simply add the files to the project file, creating relative path links to them.
The framework should now compile directly into your project. I can't emphasize enough how fragile this solution is. As files are added to your framework, they also have to be added/linked into any project that you've "link embedded" the framework.
This "solution" should only be used as a last resort. Having to repeat framework parity across multiple projects is dumb. If time goes by with the project staying static, and the framework evolves, dump the framework in the project, and re-add it. It takes less than a minute to dump/re-add the framework, and reduces the chance of error.
Apple, please help us, so we can maintain best practices. I'm embarrassed to share this solution, as it's just a horrible way to get around something Apple is not supporting.
In porting my WPF MVVM app to MvvmCross, what would be the recommended approach for persistent user settings in the Core assembly? Currently I'm using Properties.Settings for this task. Ideally, I'd like a solution that can play nicely with ClickOnce upgrades on Windows.
Thanks!
If you only want to support WPF, then you could continue using properties.settings.
If you want to support settings using native techniques on other platforms as well, then you could create an interface/abstraction for your settings and then use dependency injection to inject an appropriate settings implementation on each platform. You could do this in a plugin if you wanted to - but for getting started it's easiest to start by injecting this in your UI projects in Setup.cs (for how to build a plugin, see https://speakerdeck.com/cirrious/plugins-in-mvvmcross)
What I would probably do... is to use a portable settings implementation - either using a simple JSON file or using a small SQLite database (accessed via SQLite-net). This would enable you to reuse exactly the same code on all platforms. I don't know how this would work with ClickOnce (I don't know much about ClickOnce) but I'm assuming ClickOnce would preserve these data files during upgrades.
For portably saving a JSON file, see https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20CirriousConference/Cirrious.Conference.Core/Models/FavoritesSaver.cs
For using SQLite-net, see https://speakerdeck.com/cirrious/using-sqlite-dot-net-in-mvvmcross - but be aware that the nuget packages for SQLite-net still suffer from the open issue on x64/x86/ARM differences - see How to distribute processor-specific WindowsStore assemblies with nuget :/
I downloaded the new version of Zend Framework 2.0 and noticed that it has less features than the version 1.2, both in framework folder and externals.
What is the reason? Does Zend have a new policy to you include some features as extensions or this is related to become more lightweight?
Zend_Service(S) now have each one his own repository with his own live cycle, by this way that services can be adapted soon to the vendor API changes.
Zend_Date, Zend_Currency, ... and other locale components have been replaced by PHP 5.3 API (DateTime, NumberFormat, etc) there is a new i18N component for translates.
Other components was not in use, and others are not enough stable for to go with the main distro.
Here you have the full list of repositories for the main distro and other components https://github.com/zendframework/
In zf2.0 only standard components are included, the components that are essential for the application development. The remaining components can be included on-demand.
You can read more about this in http://framework.zend.com/downloads/
The reasons for making this such lightweight is explained by Matthew Weier O'Phinney http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements