All previous versions, of the various Microsoft.ApplicationInsights.* packages on nuget.org have all switched to being deprecated. This feels unusual for a minor release, and it's not acknowledged in the release notes. Is there a reason for this?
e.g. https://www.nuget.org/packages/Microsoft.ApplicationInsights.AspNetCore
To answer my own question for anyone else that might be wondering if they need to upgrade Application Insights packages, the short answer is no. You can keep on using the version you are on with the usual consideration for the patch and minor release notes.
This is a recent move by the Application Insights team to comply with the Azure SDK lifecycle and support policy that states:
or has been superseded by a more recent release. In both cases, the current library is deprecated in favor of a newer library.
The main driver, is that support requests are typically resolved by updating to the latest SDK version, so only 'supporting' the latest version ensures we all try that first before teams commit resources to support.
Source: Application Insights GitHub issue.
Related
I have Googled about the lastest Version of ignite ui. The only info I got is, it is "2018.2". Is there any place where I can find info about Patches stuff. e.g. I have now Infragistic.Web.Mvc.dll Version 5.18.1.40. Is it the latest one ?
The core portion of the product, which is on GitHub, follows the same versioning, as the full version. You can check all the available versions, as well as the latest one here:
https://github.com/IgniteUI/ignite-ui/releases
Here you can see our Service Release Schedule and all upcoming and current releases for all IG products.
According to this article some support for older versions of Azure are going away:
https://azure.microsoft.com/en-us/blog/microsoft-azure-storage-service-version-removal/
We have a vs2008 application that is uploading files to Azure. {Using Azure 1.2 (for VS2008) - Microsoft.WindowsAzure.StorageClient v1.0.0 - Runtime v2.0.50727}.
We can't have this break since we are using this in production.
I need to know if there is a clear way to know if this is going to stop working.
I would really like to know if there is a way to upgrade the vs2008 project to use a compatible version of the StorageClient without migrating the project to vs2015.
Your version of the library should still be supported after the service removal. You can confirm which version of the service you are hitting by running requests through Fiddler and checking the x-ms-version. As you can see in the most recent post regarding our service deprecation, we are only removing version 2009-07-17 and older as of August 1, 2016.
I am a beginner in Azure and have come across a task to change the storage version.I basically found that the versions are obsolete and need to upgrade them as per http://blogs.msdn.com/b/windowsazurestorage/archive/2014/08/05/microsoft-azure-storage-service-version-removal.aspx
So, in one of the paragraphs its mentioned
"What to change
If you find any log entries which show that version to be removed is being used, you will need to find that component and either validate that it will continue to work (unversioned requests may continue to work as their implicit version will simply increase – see above), or take appropriate steps to change the version being used. Most commonly, one of the following two steps will be used:
1) Change the version specified in the request, typically by migrating to a later version of the libraries/tools. When possible, migrate to the latest version to get the most improvements and fixes.
2) Set the default service version to one of the supported versions now so that the behavior can be verified prior to removal. This only applies to anonymous requests with no explicit version. "
Question is, how to go about implementing point 1 and 2 ?
Thanks
Since your code is written in C# and uses Azure SDK your best bet is to upgrade it to a "new enough" SDK. It's unclear whether version 2.0 or 2.1 is the lowest required. So your route is the following:
First, check if you really have to do anything.
You check which Azure SDK your service uses. If it's 2.1 or higher you don't need to worry yet. If your're unsure - use Fiddler to validate the version headers as explained in the linked to post.
If you use Azure SDK 2.0 you'd better check the version headers as explained in the linked to post.
If you use Azure SDK prior to 2.0 you are surely affected and have to upgrade.
So if you found you do need to upgrade you'll have to download and install the newer SDK and then remove references to old SDK assemblies from your projects and add references to new SDK assemblies. Then you try to build your code and maybe fix a lot of calls because SDK interfaces have changed (that's what I see migrating from 1.8 to 2.4). Once it builds you test it works fine and then you remove the old SDK version to ensure the code builds without it present.
There was a breaking change between 2.1 and 2.2 - the latter only support Visual Studio 2012 and higher. There was another set of changes in Azure Diagnostics functioning between 2.4 and 2.5 which are so long to read that I chose to migrate to 2.4 instead of 2.5.
I'm using web-jobs SDK pre-release version and from few minutes ago Im getting this warning message:
Jobs from an earlier version of the Azure WebJobs SDK have been detected. Please upgrade the jobs to the latest version in order to see their status in the dashboard. Please visit this article for more information about the Azure WebJobs SDK.
I would be thankful if you help me with this.
Later edit: the link should work now
The page for that link is not yet live. It will be published soon, sorry for the inconvenience.
Meanwhile, to upgrade, get the latest WebJobs SDK packages (notice the package names changed so you might want to remove the old ones):
http://www.nuget.org/packages/Microsoft.Azure.Jobs/0.3.0-beta
http://www.nuget.org/packages/Microsoft.Azure.Jobs.Core/0.3.0-beta
Also notice that some attribute names changed:
Where are Azure WebJob's BlobInput and BlobOutput classes?
We have an application, in which we have series of releases. The current version of the application in production was V2.1
Now we have a set of new UI Screens to be added and related changes to the application. We are planning to release these changes as V3.0.
Do we need to go with Major Upgrade or Minor Upgrade? If we go with Major Upgrade, do we need to reinstall the application? or change the version to 2.2 and go with Minor Upgrade?
Please suggest me some best way to go about with these installers.
Note: We are using Install Shield Premium for building the installer.
If the only changes you are making are to the UI of your installation wizard, there is no fundamental reason to prefer either a minor or a major upgrade over the other. Typically the choice is driven by the changes you are making to the application itself, or the files that comprise it.
A Minor Upgrade will support first-time installations, as well as provide what should be a shorter update for the upgrade experience. A Major Upgrade will uninstall what's currently there before installing the new version. Either can be done with either sets of version numbers - the difference depends primarily on whether you change your ProductCode.
See Patching and Upgrades for details. Some people prefer creating Major Upgrades because they are easier to reason about.