I'm trying to recompile a Firefox extension that has binary components for use with Firefox 5 now that the beta is out. According to this I need to rebuild the binary components. What I can't figure out is which xulrunner to download and build against from here.
Is there a table that matches up FF versions (5, 6, 7) with code names (Beta, Central, Aurora) with Xul Runner versions (2, etc)?
Any decent guide would be great.
Update
It looks like the SDK / Mozilla version number has been changed to match Firefox's version number. Based on that my guess is now this:
Firefox 5 | Beta | XULRunner 5.0
Firefox 6 | Aurora | XULRunner 6.0
Firefox 7 | Central | XULRunner 7.0
Mozilla's wiki has a section of the Firefox page that gives the mappings you're looking for, but it only covers the already-released versions.
Another page called Releases lists upcoming versions and their codenames, but doesn't indicate the underlying XULRunner version.
It would appear that you'd want "latest-mozilla-beta" (which is listed as XULRunner 5) for now. Judging by the version numbers in the newer nightlies, it looks like the XULRunner versions are going to be shifted so that they match up with their corresponding Firefox versions.
XULRunner version numbers match the version number of the Gecko engine. Firefox 3.6 uses Gecko 1.9.2, Firefox 4 uses Gecko 2.0. It has been recently decided that Gecko version numbers should be identical to Firefox version numbers so Firefox 5 indeed uses Gecko 5.0, Firefox 6 uses Gecko 6.0 and so on. You can get XULRunner nightly builds for unreleased Gecko versions under http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/ (latest-mozilla-aurora, latest-mozilla-beta and latest-mozilla-central are usually the directories you will be interested in).
Related
I have a program (.Net Framework 4.6) that reads and updates excel spreadsheet via OleDd.
I have ported this code to .Net 6 solution using the System.Data.OleDb (6.0.0) package.
It works fine on my development pc (Win 10), but when I upload it to deployment server (Windows server 2016) I get error:
The data providers require Microsoft Data Access Components (MDAC).
Please install Microsoft Data Access Components (MDAC) version 2.6 or
later.
The .Net Framework 4.6 app is working on the deployment server just fine.
I have installed:
AccessDatabaseEngine2016.exe
mdac28sdk.msi
My .Net 6 app is running in 32Bit mode
What am I missing?
Regarding a .NET_6 project I'm working on under 64bit Visual Studio with C#, and which I was in_serious trouble with, well, reading your question text brought me to rebuild this project of mine now specifically for 32-bit instead of building for "Any". This solved my_pending problem to get OLE.DB successfully opening a_connection to M$Access, which had been installed as part of 32-bit M$Office. It was a relief to finally get across my OLE.DB hurdle this way (after a good number of hours), but in hindsight I am surprised that earlier on, with .Net Framework v4.8, I can't seem to have needed this sort of bitwise accuracy.
So for what it's worth, at least in my case bitlevels were essential and crucial to get OLE.DB working under .NET_6.
We have a 5 year old application written in vaadin 6. It only uses basic vaadin UI framework functions. If we want to upgrade to a newer vaadin version that will be supported, what is the version we should go to? I understand that moving from v6 to v7 and above requires some rework. Is vaadin 8 the best version to use to complete this UI migration? How long will vaadin 8 be supported? Are the UI framework stable after vaadin 8, i.e. upgrading to higher versions do not require changes in the application? Thanks for some guidance.
Vaadin versions are either incremental or come with long-term support.
A long-term support version is maintained as an open source product for 5 years after the initial release. Additionally, Vaadin is offering commercial support for another 10 years. An incremental version is only maintained for a short overlap after the next version.
Vaadin 7 is already more than 5 years old and thus only supported based on commercial contracts. Commercial support is available until 2029.
Open support for Vaadin 8 ends in February 2022, while commercial support is available until 2032.
Vaadin 10 is still supported, but there are aren't any good reasons to choose it over Vaadin 14 at this time.
Vaadin 14 has free support until 2024 and commercial support until 2034. This is the version generally recommended for new projects today.
Vaadin 23 is planned (but not absolutely certain) to be released in the beginning of 2022 with long-term support until 2027. It might be an alternative for new projects to go with incremental versions until that.
The other side of the coin is how easy it is to update your existing project. Vaadin 7 and Vaadin 8 is roughly the same from that point of view since Vaadin 8 also includes an extensive compatibility package that covers basically everything from Vaadin 7.
The jump to from Vaadin 6 to either Vaadin 14 or Vaadin 23 is bigger than the jump to Vaadin 8, but there isn't a big difference between 14 and 23 when it comes to the work needed for migrating from 6.
Environment: Windows 10 (fresh install), using Monogame 3.6 (same goes for 3.5 for this matter) on DirectX projects.
Problem: I can’t hear any sound effect unless I reinstall DirectX.
Before reinstalling DirectX, there is no exception or status information I could use to trace why the sound is not audible. After reinstalling, it just works. Same code, even same binary.
I don’t want my users to have to reinstall DX. This will be awkward as Win10 comes with DX pre-installed.
So I wonder if someone knows which additional DX libraries I may include in project folder so that the sound effects are audible without reinstalling DX?
It's important to understand that you cannot "Install DirectX" on Windows 10 or any version of Windows back to Windows XP Service Pack 2. The DirectX End-User Runtime package (a.k.a DXSETUP) doesn't actually install Direct3D, DirectPlay, DirectSound, etc. It doesn't even include the CABs needed to install DirectX on older versions of Windows.
Not So Direct Setup
The version of "DirectX" installed is only ever updated via Windows Update, installing a new version of Windows, or some kind of Service Pack. Windows 10 includes all supported components of DirectX 9.0c, DirectX 10.x, DirectX 11.x, and DirectX 12.0 as part of the OS.
Direct3D 11 Deployment for Game Developers
What the DirectX End-User Runtime package does install is the various legacy side-by-side helper components: D3DX9, D3DX10, D3DX12, XAUDIO2.7 or earlier, XINPUT 1.3 or earlier, XACTENGINE, and the legacy Managed DirectX 1.1 assemblies. That's it. Furthermore, it installs about 100 MB of these things including every version that has ever shipped for both x86 and x64, which means your game is never going to use most of them. Likely Monogame is set up to use XAudio 2.7 which is the last version of XAudio to support Windows 7. As such, it needs just a handful of CABs from DXSETUP.
KB179113: How to install the latest version of DirectX
XAudio2 and Windows 8
Finally, the DXSETUP files that shipped in the end-of-life DirectX SDK (June 2010) are actually not the latest version of the DirectX End-User Runtime. I fixed a number of bugs in an online only April 2011 refresh.
DXSETUP Update
MindJet.com wants you to upgrade for $280+ to MindJet 2015. Older versions of their mind mapping products install into Windows 10 without any errors. However you can not start the application. When you try to, nothing happens, and there are no error messages, not even in the Windows event log.
The above steps didn't work for me, but I used the steps in this microsoft support note to enable .NET Framework 3.5 and after that was able to open and use my MindManager 9 version on my Microsoft Surface!
https://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_install/how-to-instal-net-framework-35-on-windows-10/450b3ba6-4d19-45ae-840e-78519f36d7a4?auth=1
To check if the.NET Framework 3.5 is available in Control Panel and to enable it, please follow these steps:
a) Press “Windows Logo” + “R” keys on the keyboard.
b) Type “appwiz.cpl” in the “Run” command box and press “ENTER”.
c) In the “Programs and Features” window, click on the link “Turn Windows features on or off”.
d) Check if the “.NET Framework 3.5 (includes .NET 2.0 and 3.0)” option is available in it.
e) If yes, then enable it and then click on “OK”.
f) Follow the on-screen instructions to complete the installation and restart the computer, if prompted.
This will install the .NET Framework 3.5 feature on the computer.
Support and sales do not tell or document this but you can get earlier versions to run in Windows 10. The older versions depend on older versions of .NET Frameworks. Windows 10 has .NET Framework 4.5 pre-installed but nothing older than that.
How to install the older .NET Framework versions in Windows 10:
Settings | Apps & Features | Manage Optional Features | Add a Feature |
Choose the .NET Framework 3.5, 3, 2 package install option. It should be the first in the list.
Your older versions of Mindjet/MindManager products will now run in Windows 10.
I am building an F# console application with Visual Studio 2013 Ultimate. The target framework is .Net 4.5
The version of FSharp.Core installed on my computer (presumably by installing VS 2013) is 4.3.1.0.
On NuGet there are two versions of FSharp.Core, 4.0.0 published April 12, 2012 and one with an ID of Fsharp.Core.3 verison 0.0.2 published March 5, 2013.
I am looking for guidance as to when one should use each of these versions, the version numbering is confusing me and I would have expected to find the latest production release on NuGet.
Am I missing something?
You should not be obtaining FSharp.Core from nuget. Microsoft does not publish any official F# bits to nuget today (though this could potentially change in the future). It's common for 3rd-party packages to bundle FSharp.Core (since presumably that's the version used for testing/validation of that 3rd-party component), but nuget should not currently be used as a mechanism for getting FSharp.Core updates or new versions.
The versioning story for FSharp.Core is sadly rather complex, and definitely not as simple as "higher version means newer." A key thing to realize is that there are 2 axes - what F# version does the runtime support, and what .NET framework version/profile does it target.
Below are the official FSharp.Core versions that ship with VS 2013 (find these dropped under %ProgramFiles(x86)%\Reference Assemblies\Microsoft\FSharp).
4.3.1.0 (F# 3.1/.NET 4) This is the most recent official version. Unless you have a requirement to target .NET 2, or you are using some legacy F# component that won't work with 3.1, this is the version you should use for any new desktop app.
4.3.0.0 (F# 3.0/.NET 4) These are the same bits that shipped with VS 2012. It is included so that you can continue working on F# 3.0 projects in VS 2013 without retargeting them to 3.1. You should use this if you have a legacy F# 3.0 desktop project that you are not ready to move to 3.1 yet.
2.3.0.0 (F# 3.0/.NET 2) These are the same bits that shipped with VS 2012. The only reason to use this is if you are targeting .NET 2. The .NET 2 side of things is not being developed further, btw - new features, versions, etc will be done for FSharp.Core targeting .NET 4+; the .NET 2 FSharp.Core is still fully supported, but it is frozen.
3.3.1.0 (F# 3.1/"Portable") This version targets .NET portable profile 7 (.NET 4.5/Windows Store). Use this if you are creating a component for a Windows store app and you don't care about Silverlight. This profile is newly supported in VS 2013.
2.3.5.1 (F# 3.1/"Portable (Legacy)") This version targets .NET portable profile 47 (.NET 4/Silverlight 5/Windows Store). Use this if you are creating a Silverlight component. This profile was also supported in VS 2012, and referred to at that time as simply "Portable."
2.3.5.0 (F# 3.0/"Portable (Legacy)") This version targets .NET portable profile 47 (.NET 4/Silverlight 5/Windows Store). These are the same bits that were included in VS 2012. Included in VS 2013 to enable you to continue working on F# 3.0 portable/silverlight projects.
.NET portable profiles are a big PITA and cause a ton of complexity. This site has a good summary to help understand: http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html
So for your specific scenario (new console app) use 4.3.1.0.
Edit 7/2015:
Here's a table that probably explains the story better than the wall of text above. I've tried to use colors to indicate the motivation for the version numbers. You'll see the versioning of the portable libraries was a bit ad hoc and inconsistent in VS 2012 and 2013, but is finally consistent and predictable starting with VS 2015. This is up to date with F# 4.0, which just released.
Today I would probably rather follow these guidelines
In short, you can/should reference FSharp.Core from NuGet