On the swift website you have several options / versions to choose from, but some of the packages don't seem to include swift-build, what is the reason for this?
Notably:
Swift-2.2.1 14.04 May 3
Should be similar for the version of 15.10. It does not seem to be the case with the master-branch tar-balls.
Its actually quite relevant for me to try to stay up to date as possible, since Swift reaks of memory leaks at this point in time.
The release of Swift 2.2 does not include the swift package manager, as the package manager was still too early in development to include in a release version of Swift at that point. Instead, a feature was added to the package manager to allow using the version from a 3.0 toolchain with the Swift from a 2.2 toolchain, so that people could use a more recent version of the package manager.
Related
I am working on a PCL project that is using Profile44 as TargetFrameworkProfile. When I try to install NodaTime 2.2.4 I get the following error message:
Could not install package 'NodaTime 2.2.4'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.6,Profile=Profile44', 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.
Do I have to downgrade to .Net 4.5 or what options do I have?
Noda Time 2.x only supports the Target Framework Monikers netstandard1.3 and net45. There's no direct PCL support, although some environments that traditionally used PCLs now support .NET Standard.
The 1.x series supports PCLs via Profile328, which has a NuGet target of "portable-net4+sl50+win8+wpa81+wp8". For environments that don't yet support .NET Standard, trying the 1.x series is the best option.
Note that I'm expecting Noda Time 3.0 to probably target netstandard2.0, although I'll still keep the older versions up to date with respect to time zone data.
I installed the Westwind-Globalization package 2.1 but the libraries installed are misssing the Westwind.Globalization.JavaScriptResourceHandler-class. I downloaded 2.1 from git-hub and compiled the Westwind.Globalization.Web-project anew. Now the class exists and my code works again.
Did I do something wrong or is this class deprecated/discontinued?!
You need to install the Westwind.Globalization.Web package, which includes the JavaScript resource handler. The release version of the libary rearranged the breakout of resources into separate packages. I suspect you had an older, or beta version that came from before when the change was made (a beta most likely).
When I try to update or to install dialog support package I get the error:
Could not install package 'MvvmCross.HotTuna.Touch.Dialog 3.5.0'. You are trying to install this package into a project that targets 'MonoTouch,Version=v1.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.
The issue is you are still targeting the old 32 bit only iOS api (the MonoTouch.dll). All apps being written for the store must support 64 bit and 32 bit (Xamarin.ios.dll).
You can I believe get a build of mvvmcross 3.5 that will support the old apis, but I'd look at upgrading your project to support the new iOS apis. Xamarin produce some good docs here: http://developer.xamarin.com/guides/cross-platform/macios/32-and-64/.
This goes without saying but make sure you have everything in source control first before upgrading just in case. Once you have upgraded you should upgrade all mvvmcross components to 3.5
Good day! I've got a problem with linkage on Linux using gcc. For example, I've compiled project on one machine and linked it with libGLEW. When I'm trying to run it on another machine - it can't find libGLEW, because first machine has libGLEW.so.1.7 and second has libGLEW.so.1.10.
ldd shows me, that it dependent on 'libGLEW.so.1.7'.
after creating symlink 'libGLEW.so.1.7 => libGLEW.so.1.10' everything works fine, but is there a way, to store 'libGLEW.so' as dependency instead of 'libGLEW.so.1.7'?
What makes you sure the function interface of GLEW doesn't have changed?
Or even the content of version 1.1 to 1.7 is still the same?
If it is build with 1.7, it also depends on 1.7.
So you shouldn't run it on another version of GLEW, except the api documentation of GLEW tells you that this cross versioning is possible for some reason (But I couldn't imagine that).
Otherwise also build it with GLEW 1.1 in addition
(because as if all features you use from 1.7 are also supported by 1.1 and for some reason you have to support both versions), so to serve different versions fo your programm for different versions of GLEW would be the best and valid way.
If that is not the case make it for the user as requirement to be on Glew version 1.7 or higher.
But there is no safe way of working around to archive what you want.
And there is not a gcc or any compiler command for that at all.
I have Awesomium SDK 1.6.6 installed and i want to upgrade it to the 1.7 candidate how could i do that. because when i downloaded the 1.7 i find it is only consists of some files and no setup file included (like the 1.6 one)
We have not created an installer for the Release Candidates of version 1.7. RCs are not stable releases. There will be one again when 1.7 goes stable and 1.6.6 installations will then be able to automatically upgrade to 1.7.
Are you looking to use the .NET wrappers? If so, you should be able to download and extract the files anywhere, then in your project, just add references to Awesomium.Core.dll and either Awesomium.Windows.Forms.dll or Awesomium.Windows.Controls.dll, depending on whether you're using Winforms or WPF. The dlls are located in awesomium_1_7_rc3_v3_sdk_win\wrappers\AwesomiumNET\Assemblies\ within the archive.
I believe the setup.exe you're expecting to see is only used for extracting the files to a specific location and providing you with some helpful links in your start menu, so you aren't missing much by not having it.