How can Partial Artifact download be configured in TFS2018 Update 2? - azure-pipelines-release-pipeline

According to the TFS 2018 Update 2 Release Notes, the partially downloading artifacts feature was added. This is further backed up on the uservoice item.
However, I cannot seem to find where to configure this option within the release template editor.
They provide a screenshot:
However, I don't have anything like that:
I am confident I am on the tfs 2018 Update 2 release as this is the version specified in the TFS Admin Console:

The release notes are wrong, check this feedback: TFS 2018 Update 2 RC - Select artifacts to download not available
Partial downloading of artifacts feature isn't available in TFS 2018
Update2 RC. Since this feature has dependency on couple of other
features and those features are not enabled in TFS 2018 Update2, we
chose to not to roll it out. Having said that feature showing up in
docs is a bug - we will remove that section from docs.

I have validated what you're saying. My best guess is that Microsoft made a mistake. It's already a feature in VSTS, so it looks like the release notes are wrong.

Related

Is Enterprise Library still being updated?

I'll be porting an asp.net website in Net 2.0 to a more recent version of .Net 4.5.
I'm looking for more modern libraries to use for SQL Server connectivity, and I noticed that the last update for Enterprise Library was done in April 2013.
Is Enterprise Library still being used or is there something newer?
Thanks.
The CodePlex project page for Enterprise Library (which goes read-only Nov 6, 2017) says:
This project is no longer under development.
Unity has new ownership and has relocated to GitHub.
The remainder of
the application blocks will no longer be developed. However, the
source will continue to be available. We encourage any interested
parties to fork the source as desired.
So, other than Unity it's looking pretty dead. It's unclear if MS will be keeping read-only CodePlex online or not.

Track functionality missing from latest SDK update

I updated my pods today and got the latest 6.0.0 version of the SDK. However this seems to be missing the "track" function that was used to interact with the whispers setup on the dashboard. What is the alternative for this?
Whispers support, including the track API, was removed from all three Smooch SDKs in the latest major version releases, since the Whispers feature is currently deprecated and set to be removed from the platform on October 1st. The deprecation was communicated to all Whispers users at the beginning of July 2017.
If you send an email to help#smooch.io describing your use case, there may be the possibility of a workaround, but the newest SDKs were not designed to support Whispers or Whispers-style use cases, so workarounds won't be possible in every case.

"One or more projects are incompatible with UAP,Version=v10.0" Issue [UWP]

I've been developing UWP app until I got this error (picture below). I've searched for solution but I couldn't find anything. It doesn't even say which package is the incompatible. How can I find the incompatible package in my solution? Also is there any way to re-create project.json by automatically? I ask it because I changed something on project.json and broke it more.
Also I'm using VS2017 and I'm able to run project without issue. I just can't update package.
Thanks.
(github link for project if you want to look at it.)
I used your GitHub https://github.com/almorax/dota2-handbook-uwp project to troubleshoot the problem and looks like the problem is with the way the nuget package is referred in "Dota2Handbook" project. In other projects, you have used "PackageReference" way to refer the nuget package however in "Dota2Handbook" project you are using project.json to refer nuget package. When I changed "Dota2Handbook" project to use the "PackageReference" way then I was able to get the latest package.
Note: You will notice that "Dota2Handbook.Infrastructure" project already use the new way to refer Nuget packages
More details on PackageReference : https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
What happened to me is that I have UWP projects that were made in VS 2015 and initially targeting Windows 10 RTM. These projects where updated to VS 2017 and to target Creator's Update. All worked fine, and all projects still used the original project.json style.
Then I tried to create a new Windows Runtime Component project and target Creator's Update initially. Targeting Creator's Update in VS 2017 causes the project to use the new PackageReferences project style. This produced the errors shown in the above question when I referenced the WinRT component from the UWP app.
Rather than converting the all of my legacy UWP project files to use the new format, I target the new UWP or WinRT Component library to Anniversary Edition (which uses the older project.json project style), then retarget to Creator's Update.
Of course, at some point updating the project file may be appropriate, just know that it will no longer be supported by VS 2015. Conversion steps are illustrated here.

Is OpenDJ, OpenAM and OpenIAM free software

What has been the experience of folks who have already been using OpenDJ and OpenAM? Older versions seem free to use but the new releases don't seem to be free for use. How do they compare to the existing commercial offerings? They look like a better option than using OpenLDAP with CAS but don't look free.
Below you can find answers depending on when this question was asked just for the sake of history.
ANSWER AFTER April 3rd, 2017
With the recent changes made to the business model here you can find the key details you will need to know:
The latest versions of the main products have been firstly renamed, but secondly has been re-versioned to match ForgeRock's Identity Platform views:
OpenAM 14.0.0 -> Access Manager 5.0.0
OpenDJ 4.0.0 -> Directory Services 5.0.0
OpenIDM 5.0.0 -> Identity Management 5.0.0
OpenIG 5.0.0 -> Identity Gateway 5.0.0
The products listed above were all released under a commercial licence, meaning:
The ForgeRock contributed source code (i.e. ForgeRock's intellectual property) is not licensed under an open source licence.
All source code that does not solely belong to ForgeRock (e.g. original source code that belonged to Sun, or source that had open source contributor's work associated with them) will be still available under the CDDL licence and can be obtained as detailed under forgerock.org.
All ForgeRock IP is licensed under a non open source licence.
The products released under the commercial licence can be evaluated for 60 days only.
At the same time of the official release of the new products, community editions have been released for the Open* products:
The community editions are essentially the latest maintenance releases of the last EOL'd versions of the products.
Since these are maintenance releases, they are meant to be firstly more stable, but secondly slightly more secure (only slightly since these versions have not been updated to include the security fixes that have been issued since these versions' original release date).
The community editions can be found under forgerock.github.io
With these new releases every community member will have to make a decision themselves: do they want to go for the latest, but EOL'd stable version of the product, or do they want to try their luck with the latest public, but likely to be less mature software versions (like OpenAM 13.0.0 that was released before the business model change).
Whether community versions will be released/updated by ForgeRock in the upcoming years is currently unknown, no such information has been publicly provided.
Short of an official announcement from ForgeRock, please have a look at this topic in the ForgeRock forum for more details.
To summarize:
The Open* products are still open source and freely available, however they are no longer being publicly developed by ForgeRock. Whether new community versions will be made available is yet unknown, but given the current example, each year the community would get access to an EOL'd version of the product..
ANSWER BEFORE April 3rd, 2017
Here are some facts about the projects and the licensing in general:
Only major releases are made publicly available, which means the source code is available in the format of an SVN tag, whilst the binary that can be downloaded from BackStage will have the binary license on it.
The binary license allows people to test out the product, but it prevents them from using those binaries in production environments without support subscription.
Maintenance versions are not available publicly neither in source nor in binary format.
Each project's trunk (or master) is publicly available, which means that in one shape or form every single bugfix is available, so with some luck it should be possible to cherry-pick important fixes from trunk onto your own special maintenance version.
Each product is relatively simple to build (except maybe the web agents), and as such it shouldn't pose much of a risk to your deployment (ForgeRock does have customers who are building their own artifacts for their deployments, so it is really not a rocket science).
Downloading the artifacts from BackStage only requires some skills on working with agent protected applications, here is an example curl command:
$ curl -O -H "Cookie: fr_sso_sess_prod=AQIC5w..." https://backstage.forgerock.com/downloads/enterprise/openam/openam12/12.0.0/OpenAM-12.0.0.war
Unfortunately it is common that the major releases have some annoying bugs, for those, backporting is relatively simple, since the difference between trunk and the latest major release shouldn't be too big, so you should be able to handle those by manually backporting the fixes. Since major releases happen every ~year or so, you don't have to live with these local changes for too long fortunately.
The projects have active community, and getting help with any kind of issues shouldn't be too difficult (let it be a deployment issue or how to build the projects locally)
Probably I should mention that I'm a ForgeRock employee, so take my comments as you please.
Just to clarify: when you build trunk on your own, you do not have to buy subscription. Only ForgeRock enterprise builds should include the binary license. When building your own stuff, it is you who creates the binaries, hence you can simply decide to leave the binary license out of it.
I'll answer your question in two parts:
First as it compares to existing commercial it's actually a very good solution, as it scales, and it's very feature rich. You can go to the site and read all about the features.
The second part of newer version requiring subscription is somewhat wrong. Mainly because there are subscription downloads from forgerock.com. I assume this are for support service contract reasons that one must purchace. If you want to run the latest version just download the nightly builds forgerock.org, and you will be running the latest version. Lastly I will echo Ludovic's comments about the confusion of free.
[Community] - https://forgerock.org/
[Commercial Support] - https://forgerock.com/
PS. I'm in no way associated with forgerock.
I think you are confusing free as in Free beer and the freedom of open source.
This said OpenAM and OpenDJ are enterprise ready products, mature and used in a large number of mission critical environments including governments, telecom operators, financial institutions, insurances...

MSSCCI compliant Mercurial client

Hi I am looking into a Microsoft Source Code Control Interface (MSSCCI) compliant Mercurial Client for integrating Mercurial into my IDE (LabVIEW). I thought HgSCC was getting close since it claims it uses the MSSCC interface for it's integration with Visual Studio, however it doesn't turn op in LabVIEW as an option.
Does anybody know a MSSCCI compliant client or can verify that HgSCC is indeed such a client and LabVIEW is just lazy in recognizing this one?
I looked at the registry key used by LabVIEW HKEY_LocalMachine\SOFTWARE\SourceCodeControlProvider\InstalledSCCProviders which only lists PushOK's SVNSCC client.
The first version of HgScc was MSSCCI compliant.
You can get it here (http://www.newsupaplex.pp.ru/hgscc_news_eng.html), scroll at the very bottom to the news dated "24 may 2008". There you can find a download link. Also, that version was tested only with MSVS 2005/2008, so it may not work with LabVIEW.
The recent versions of HgSccPackage supports only MS SCC Package API (MSVS only), which is not MSSCCI compliant.
Have you tried VisualHG?