We've upgraded to latest Azure Management libraries from Nuget and are seeing that the calls to CloudContext.Clients.Create-various-management-clients no longer exist. Is there a substituation somewhere else for this functionality?
TIA
So, it appeared that there is a decent amount of updates in the "Preview" mode of Nuget libraries for this.
It looks like some libraries, /at this time/ are released as stable releases that point correlate with dependencies in the "Preview" state. So, all of the CloudContext.Client extension methods are only present in the Preview library as Microsoft is migrating namespaces from Microsoft.WindowsAzure to Microsoft.Azure
Very confusing at the moment, hopefully things will clear up
Related
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 went to update the Azure storage client nuget here, and before pulling it read the changelog. In the changelog they say "support for 2015-07-08 REST version. Please see our REST API documentation and blogs for information...". I have looked all over and can't find any documentation for that API version (2015-07-08) of what was changed. Does anyone know what was changed and/or where the changes are documented?
Version 7.x of the client library is based on version 2015-07-08 (the latest version). However, the change to the service with this version, as compared to version 2015-04-05, is very minor. The only change is the addition of the GetPageRangesDiff/GetPageRangesDiffAsync methods on CloudPageBlob. These methods support incremental snapshots (see https://azure.microsoft.com/documentation/articles/storage-incremental-snapshots/). There is no other change to the service.
Also see https://msdn.microsoft.com/en-us/library/azure/ee691973.aspx for the change to Get Page Ranges.
We will provide information in the versioning section for 2015-07-08 soon.
Didn't find what was exactly changed, but I think the documentation refers to https://github.com/Azure/azure-storage-net/tree/master/Documentation and blogs at http://blogs.msdn.com/b/windowsazurestorage/.
Are there any plans for the ServiceStack packages to start using the SemVer standard? We just had an unfortunate circumstance where we were broken by the interface breaking changes introduced in 4.0.44 from 4.0.43 around OrmLite.
We are a sizable commercial customer and have a custom implementation of a OrmLiteDialectProvider for one of our DBMSs, it all seemed good upon the initial upgrade in our web application, however as part of testing the changes around type converting broke our system. This wasn't initially evident as part of the upgrade because our custom implementation is in a NuGet package which overrides OrmLiteDialectProvider.ConvertDbValue on version 4.0.38 which is now gone. There were no binding issues because it is only a minor version difference.
NuGet adopted SemVer back in version 1.6.
Having the SemVer standard would make it a lot easier for us to know when interface breaking changes have been made, without having to dig through the Release Notes page.
NOTE: The release also didn't indicate that the old method had been removed and upgrading would break any custom implementations.
UPDATE FROM RESPONSE
Anyway, fair enough answer. I can appreciate it would be difficult to track each package individually. In our case we wrote a custom dialect provider as we have a legacy DBMS that wasn't supported and this appeared to be the way we were supposed to add the support. We wanted to use ORMLite because we use the rest of ServiceStack and it's a fantastic product.
The new way to support the types is a great improvement and actually made our implementation easier.
We actually ran into this issue because we do always keep our ServiceStack packages inline and were upgrading the ASP portion for some fixes to the WSDL generation and this came along as part of our upgrade.
ServiceStack adopts a single rolling version for all NuGet packages which all share the same Version number. Of all ServiceStack's 60 NuGet packages it's likely there's a breaking change to at least one of the packages so semver would be useless, you should also never mix and match different versions of ServiceStack together - when you upgrade, upgrade all packages to reference the same package versions. We do aim to keep user-facing breaking changes to a minimum, by looking to deprecate old API's first, maintain parallel API versions for a while then list the new API's release notes.
IOrmLiteDialectProvider is not a user-facing interface
However IOrmLiteDialectProvider is not considered a user-facing interface since it should be extremely rare that anyone implements their own custom provider. It's also the interface for specialization for all RDBMS's and often changes with every release to support new features, internal refactoring, optimizations, etc. E.g. implementing Type Converters was a major internal refactor that required changes to IOrmLiteDialectProvider but did not affect OrmLite's external user-facing API, later releases includes optimizations requiring further changes, again this doesn't affect OrmLite's external user-facing API.
SemVer won't help here, every ServiceStack version potentially has a breaking change in some of the packages and we have no intention to complicate each release by versioning each of the individual packages differently. The issue you're having is depending on an unstable Interface that's not intended for customization. It's not treated as a user-facing API so we don't try to maintain compatibility with existing versions or publish breaking changes which happens nearly every time we add features / optimizations to OrmLite. You should instead check the commit history of
IOrmLiteDialectProvider for any changes to this interface.
At Latest API documentation NodaTime.Serialization.JsonNet is shown as a part of NodaTime library.
But I can't find it anywhere. Here's the NodeTime in ObjectBrowser in my VisualStudio.
I even looked into NodeTime.Testing and haven't found it.
I don't know where to look for it anymore. These two (NodeTime and NodeTime.Testing) are only packages available over NuGet.
From the page you linked to:
Code in this namespace is not currently included in Noda Time NuGet packages; it is still deemed "experimental". To use these serializers, please download and build the Noda Time source code from the project home page.
For 1.2, we'll be distributing a separate pre-built assembly and NuGet package, but that's not quite ready yet, so for now you'll have to build your own.
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/