Why is IDMF not supported on AX 2012 R3 - axapta

I see that IDMF was released today and it's supported for every 2012 version barring R3.
Is there another product that'll take it's place?
Is the development team still working on the R3 version?

According to the comments to the blog entry Microsoft Dynamics AX Intelligent Data Management Framework 2.0 released they are working on an update for R3 and plan to release it in mid September.

Related

What happened to the Teradata Kylo product?

GitHub activity is just empty last month, at least
download links for the latest release 0.10.1 (March, 2019) lead to nowhere
same thing for VirtualBox images - AWS S3 bucket does not exist
My questions are:
Is the project dead?
Is there any open source active project which supersedes Kylo?
According to the post pinned at the top of the Kylo community Google Group, Teradata decided to discontinue Kylo development and support in early 2019 and no new sponsor stepped forward to take over the project
Here is the message posted in the Kylo Google Group:
Google Groups State of Kylo project matt.hutton
Feb 12, 2020 4:18 PM
Posted in group: Kylo Community
Teradata made the decision to discontinue Kylo in early 2019. Teradata
had been the sole sponsor of the open-source project and offered paid
corporate training, consulting services, and enterprise subscriptions
for support. The team was unable to immediately secure a new sponsor
and devs have moved on to other projects.
The last official release of Kylo was March 2019. The downloads of
the RPM and sandbox are no longer available but you may still build
the RPM (or TAR) from maven.

Future Of NAV and AX

May not be the correct forum but do you guys have any news regarding the future of MS NAV and AX.
I have heard(from AX Veterans) that Microsoft will stop support of AX and NAV by 2020. They are going to replace it with Office 365 based new ERP.
If this question should not be here then I apologize in advance but I am worried about our future hence the question
This is the wrong forum, but I'll answer anyway.
AX is not going anywhere right now and if anyone says otherwise they're wrong. What you're probably hearing is Microsoft is ending support of the 2012 version in 2021...that's because they have a newer version out. It's equivalent to ending support of Windows 7 because we're on Windows 10 now.
These are the main active versions of AX in order (gotta love their naming conventions):
AX 4.0 (Support has ended)
AX 2009 (Support ends 2018)
AX 2012 (Support ends 2021)
Dynamics 365 for Operations
Dynamics 365 for Operations (aka D365fo aka D3fo) is the latest version and Microsoft is putting tons of weight and development into it. The core of it is still developed in X++. I also predict it will be the last version of AX and support will not end.
Dynamics NAV however I know very little on, but I believe NAV is being replaced with Dynamics 365 for Financials, which was formerly called "Project Madera", which was based on NAV. I could be wrong here and maybe D365 for Financial is the cloud version and NAV is the on-prem version. I don't know honestly.

Visual Studio Package for 2005/2008/2010?

We are looking to turn an internal tool we have developed into a Visual Studio Package that we would sell to other developers. The tool will impact the custom editor and/or custom languages.
Visual Studio 2010 has redesigned the API's heavily to simplify much of the work involved for these types of integration but the key question we have is:
What is the typical adoption pace of new Visual Studio versions? Is there any information out there on adoption rates based on history? How many shops are still using 2005?
This will help us to consider whether to target just 2010 using the new APIs or whether trying to go back and support 2008 (maybe 2005) and testing it forward.
The short answer:
I'd primarily target VS2005 (as you shouldn't have much trouble getting a 2005-specific add-in to work in 2005/2008/2010 and thus will maximise your potential market).
The longer answer:
As you move from 2005 to 2008 to 2010, it gets progressively easier to write addins. In particular, the new extensibility features in 2010 make it much easier to build and deploy extensions (the older add-in and package systems used in 2005 & 2008 are much more painful to get working).
However, quite a large percentage of users still use 2005 (indeed, there are still a lot of people using 2003 and VS6), but I'd guess that most are now on 2008. Don't expect particularly high percentages of 2010 users until at least SP1, as a lot of companies won't even look at it until it's been out there for at least 6 months and any teething troubles are sorted out. So at present if you want a large market, I think you have no choice but to target 2005 and 2008.
As a general rule, if your add-in works in 2005 it is likely to work well in 2008 and 2010, so targeting the add-in at 2005 is the best bet if you want a large market. Unless there is a specific feature of 2008 that you need, then in most areas there is little difference between 2005 and 2008, so I'd advise you to start by targetting 2005 and only jump up to 2008 if you find a problem that can't easily be solved unless you use the 2008 APIs. This should work fine in 2010 as it's well supported, but there is no guarantee that future Visual Studios will continue to support add-ins.
The alternative, as you say, is to ditch the old "add in" interfaces and use the new 2010 extensibility APIs. This will make development easier, gain much more access to the internals of 2010, and be more future-proof... but it will take months/years for the market size to build.
Well, the larger the project, the more time it will take to move from 2005 to 2008 and 2010.
I know many projects that are still in 2005, so, if you can afford it - make a 2005 version, 2008 and 2010. Large project usually have funds to buy staff...
If you can afford only one version of the product, goto 2010, in the long term... this is the best option.
(2010 will start getting market share in a few days/week, If you can offer the product in less than 6 months, you should target the older versions first, as they will rule the market for at least one more year).

Does TestDriven.NET work with VS Express?

Does TestDriven.NET work with VS Express?
EDIT:
Yeah, I just installed it and noticed that it wasn't working. It looks like a really cool program.
According to the release notes for TestDriven.NET, support for the Express editions of Visual Studio was removed in 2.8 (2.08).
I have a vague recollection of the author of TestDriven getting into all sorts of bother with Microsoft threatening to revoke his MVP status unless he modified it to only work with the non-free versions of VS.
See here for all the gory details.
The front page states that it "supports all versions of Microsoft Visual Studio" but the release notes indicate otherwise:
"Jamie Cansdale and Microsoft Corporation have agreed to concentrate on working together on future releases of TestDriven.Net for Microsoft's officially extensible editions of Visual Studio, as opposed to spending time litigating their differences."
Officially extensible version don't include the free ones, unfortunately.
Doesn't look like it (look in the bottom right)
I seem to remember Microsoft insisting that it not work on the Express versions, and some blog posts around that.
Small note: The personal edition of TestDriven.Net 3.9 does indeed work with VS 2015 Community Edition.

upgrading Biztalk 2004 to Biztalk 2006 R2

I have a client running a 1/2 dozen or so orchestrations running on Biztalk 2004 (that I wrote) that they use to exchange cXML documents (mostly too send orders) with their suppliers. It has a ASP.NET 1.1 front end. It uses the SQL adapter to store the parsed cXML. I gets & sends the documents via HTTPS.
My question: Is the upgrade to Biztalk 2006 R2 as straight forward as MS says? Any advice or things I should watch out for?
We finished a similar upgrade last year with little effort other than importing the projects into Visual Studio 2005. The upgrades were without issue. The biggest problem we had was with the various deployment scripts we used. There was a bit of rewriting to work with some of the new features of 2006. We also had to adjust to the multiple-host model for our apps. But all in all, no problems - just more features and API changes on deployment.
Best of luck.
At some point you will want to review the recommended tuning parameters for BizTalk 2006 R2 - I've prepared a list that may be helpful of the relevant resource links
http://intltechventures.blogspot.com/2008/11/2008-11-01-saturday-biztalk-2006-r2.html

Resources