Years back, there was a Microsoft package manager called PackageManagement (aka OneGet), which seems to be based on PowerShell command conventions, and was extensible.
Recently, Microsoft introduced another package manager tool known as winget, which is still considered pre-release. It seems not to use the PowerShell conventions.
What is the relationship between these two?
Is WinGet going to replace OneGet, or will there be some sort of interop?
There is no relationship other than both were created by Microsoft, apparently by different teams at different times.
PackageManagement (formerly OneGet, est. 2014) is a unified manager that does not have its own repository. It relies on other providers instead (for example ChocolateyGet, PowerShellGet). Since it is all PowerShell, it offers good CLI and scripting experience.
WinGet is still in preview (as of August 2021). It will be part of App Installer app distributed through Microsoft Store. WinGet has a repository of packages maintained on GitHub. The client is written as native C++ console application. All output is text-only and lacks all the nice things PowerShell gives us.
There is a third-party OneGet provider for Winget and also quite strong user voice to add official PowerShell support. See the following GitHub issues:
https://github.com/microsoft/winget-cli/issues/221
https://github.com/microsoft/winget-cli/issues/674
WinGet gets regular releases, so there is hope WinGet will improve and add official PowerShell support.
Related
I am using SAP Cloud SDK (Java flavour) to create an extension application of SuccessFactors.
I sadly discovered that the Jenkins pipeline does not allow me to use any other service than the ones listed here: SCN Blog (scroll to the Appendix).
This does not make so much sense to me, as now the SDK can be used - and it is sponsored to be used by SAP - also with SaaS in its ecosystem, SuccessFactors being one of them.
Any hint? Can this check be somehow "bypassed"?
Thanks,
Roberto.
Please note that the blog post is quite old, have you verified your assumption that it does not work with SuccessFactors API?
Nonetheless, we recently introduced a configuration option which allows you to disable certain checks, cf https://github.com/SAP/cloud-s4-sdk-pipeline/blob/master/configuration.md#s4sdkqualitychecks
checkServices is what you would want to disable in your scenario.
As stated by Florian in the comment and following the Project Piper documentation, parameters "checkServices" and "customODataServices" can be used to customize the behavior of the pipeline when running upon a non-Business Hub API.
"checkServices: false" will completely deactivated the check, whereas "customODataServices: [ yourApiName ]" will skip the check just for the specified services.
These 2 libraries seem to serve a similar purpose: to securely store and control the access to tokens, passwords, API keys, and other secrets.
I have been using Microsoft.Azure.KeyVault with some success, not for configuration secrets, but for keys.
Not until recently did I discover Azure.Security.KeyVault.Secrets.
In release notes I found this:
Updated Microsoft.Azure.KeyVault with its successor Azure.Security.KeyVault.Secrets to resolve key vault references.
What are the distinguishing attributes of the 2 libraries, and how to determine the appropriate choice.
Should I interpret the release note to imply Microsoft.Azure.KeyVault is obsolete or will be deprecated?
What are the distinguishing attributes of the 2 libraries, and how to
determine the appropriate choice.
The package Azure.Security.KeyVault.Secrets is the most up-to-date version of the Key Vault client library, which is recommended to use for any new project. For main differences from the legacy one, see this
Major changes from Microsoft.Azure.KeyVault. For usage, please refer to this doc.
The other package Microsoft.Azure.KeyVault is now a legacy one, if you have some old projects which use it, you can keep using it. For usage, please refer to this doc.
You can refer to this article for more details why these new client libraries(including Azure.Security.KeyVault.Secrets) are published.
Should I interpret the release note to imply Microsoft.Azure.KeyVault
is obsolete or will be deprecated?
It is hard to say if the old one will be deprecated in the future. At least from the
Release History, it says the new one is not a direct replacement for Microsoft.Azure.KeyVault(like other azure services, for example, azure storage service published a new version package recently, but not officially pronounced the old one is deprecated). But we suggest you should use the new one in any new create project like it says in the doc, a screenshot of this:
Hope it helps.
I am using ODM 8.10 and want to automate building rule app files. The code is currently configured in the old Classic Rule Project, and we are trying to avoid migrating to Decision Services at this time. I have found build jars for Decision Services but nothing so far for Classic Rule Projects. There must be a way to do this as the rule app jar files are created in the eclipse IDE when you deploy/export a ruleApp. I am trying to find out the jar files the IDE uses and the commands it calls to execute the rule app builds.
Re: "There must be a way to do this"
But you will not necessarily have access to it. The ODM product developers have experience, source code, documentation, and other tools that you do not have access to.
Having said that, there is an build/deploy API that you may be able to access via ANT. I haven't used it since switching to Decision Services when that became feasible in ODM 8.7. Standard practice before that time was to automate deployments via Ant and a "headless" version of Eclipse. If the latest online docs don't describe it, you might try the older docs.
WARNING: Classic Rule Projects are a dead end! Not only will all your effort building them in a non-standard way be wasted, I believe that it will likely be more trouble than just migrating to Decision Services (which is not usually that difficult).
What's the difference between these two assemblies and when should I use each? I find that there are class name collisions between them so I imagine that I should only use one.
Example
Microsoft.WindowsAzure.Storage has Microsoft.WindowsAzure.Storage.Table.CloudTableClient
Microsoft.WindowsAzure.StorageClient has Microsoft.WindowsAzure.StorageClient.CloudTableClient
This seems very confusing. I can't imagine that Microsoft intends these to both be used in the same project.
Microsoft.WindowsAzure.Storage is version 2.0 of storage client library while Microsoft.WindowsAzure.StorageClient is the older version. There have been many changes in version 2.0 of the library (some of them are breaking). If you're starting new, I would actually recommend using 2.0 of the library as I found it more intuitive and easy to use than the older version. If you have an application which makes use of 1.7 version of the library, before you decide to upgrade, I would actually recommend reading the following blog posts by Windows Azure Storage Team:
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/introducing-windows-azure-storage-client-library-2-0-for-net-and-windows-runtime.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/windows-azure-storage-client-library-2-0-breaking-changes-amp-migration-guide.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx
However please note that there're still some components that your application might be using which has a dependency on storage client library 1.7. Windows Azure Diagnostics is one of them. So for some time you will need to use both versions. Good thing is that you can use both versions simultaneously in your project.
Hope this helps.
EDIT:
I also wrote a few blog posts about migrating code from storage client library 1.7 to 2.0 where I covered some basic scenarios. You can read those posts here:
Migrating blob storage code: http://gauravmantri.com/2012/11/28/storage-client-library-2-0-migrating-blob-storage-code/
Migrating queue code: http://gauravmantri.com/2012/11/24/storage-client-library-2-0-migrating-queue-storage-code/
Migrating table storage code: http://gauravmantri.com/2012/11/17/storage-client-library-2-0-migrating-table-storage-code/
I am looking for an Opensource lightweight IAM to be used in development as a substitute for the real commercial IAM in production. Something with basic IAM functionalities, easy to install & easily configured to inject HTTP headers like user group.
Is OpenAM a good option? Any recommendations?
OpenAM comes from a very good pedigree...is forked from OpenSSO which is open-sourced code from the original SUN Access Manager product. OpenSSO was abandoned by Oracle after the Sun acquisition, so another company took it over and promoted a developer community around it.
Overall its a good choice for your requirements; that is:
Production-ready - yes, this version and previous versions have been used in production implementations
basic IAM functionality - it contains basic web access management functions and more than a few advanced features.
Inject HTTP headers - Yes, this is a standard function among web access management products.
In the past, a limitation with OpenAM/OpenSSO is that it required Sun Directory as the configuration store; however, this has changed with recent releases allowing other directories to be used.
Expect that installation and configuration of OpenAM to be rather command-line intensive; that is, with a minimal package installation and then options set in config files or thru utilities.
Hope that helps...