I have an MVC App which uses Azure AD, it works very well using the WindowsAzure.AD.Graph.2013_04_05 helper project that Microsoft made available. This project is now outdated, but looking at the new Nuget Package, the two require code changes.
I have two questions, How long can I use the old one before I find myself locked out of my own app. Second, has anyone migrated between them?
What I have is very simple, its just an Auth Filter which checks if a user is in one or more groups.
You should have at least a year from the announcement of a REST version being deprecated; a REST version is not the same as a NuGet package version, so you'll need to understand the underlying version in use.
Please refer to this Microsoft support policy on Azure-related REST APIs and libraries: http://support.microsoft.com/gp/azure-cloud-lifecycle-faq
Related
As an opensource .Net ECMS, Sensenet seems to have a lot of features, anyway in their developer blog, it seems they are working for an SN7 version with more goodlooking UI.
Do you have any info, when it will be released?
Yes, we are working on SN7 for some time now. Part of that work is to partition this huge product into smaller components. The plan is to release the core layer, the Content Repository (without UI) on github soon. After that the rest will follow gradually, as optional packages. The main focus now is on the platform with an easy-to-use client api.
I'm looking for a solution on how to deal with API versions in ANYpoint API manager. At the moment it is possible to create a new version of an API. But it is not possible to distinguish between different OTAP environment. In my situation it could be possible that a test environment has a newer API version than production. Do anyone recognize this issue and how did you solve it?
Currently, there are no environment promotion capabilities per se in Anypoint Platform. Having said that, there are a number of things that you can do that can help in that regard, for example:
- You can export an API from Organization A and import it on Organization B.
- You may define different sub organizations, to reflect your OTAP environment structure.
In general, it is not strictly bad that on QA, Stage or UAT environment, you have a newer API version than in Production, if you plan to implement such version in there.
Just my 2c, Nahuel.
As far as i understand if we want are going to create multiple apis then RAML versioning should be followed. what i do i can share with others.
development raml version= 0.1.0
First major release version=1.0.0
if there is any minor change then we can do 1.0.1
if there is any major contract breaking change then we can use 2.0.0.
What are the differences between aspnetcidev and aspnetvnext?
I see that aspnetcidev says "quick builds", but what does this mean?
Jan 29, 2016 edit:
This information is now part of the ASP.NET wiki: https://github.com/aspnet/Home/wiki/NuGet-feeds
The ASP.NET build system uses 3 myget feeds for each branch + nuget.org.
aspnetvolatile<branch> (aspnetvolatiledev/aspnetvolatilerelease)
aspnetci<branch> (aspnetcidev/aspnetcirelease)
aspnetvnext (dev branch)/aspnetrelease (release branch)
After each repo under github.com/aspnet builds successfully, each package produced by it is pushed to the corresponding volatile feed.
After the graph of repos is build, we trigger the Coherence build. This build verifies that the packages have matching versions and their references are correct (that they are coherent). Then, it pushes them to aspnetci<branch>.
Once the Coherence build passes, we run all our tests on the packages in the aspnetci<branch> feed. If the tests pass, we sign the packages and ship them to aspnetvnext or aspnetrelease
So the differences are:
aspnetvolatile<branch>
latest packages
possible not coherent
not tested
not signed
updated on every checkin
mostly used to diagnose build failure
aspnetci<branch>
possible not latest
coherent
not tested
not signed
updated when all repos build successfully
used by our build system
aspnetvnext/ (aspnetrelease|nuget.org)
possible not latest
coherent
signed
tested
updated when everything works
used for stable packages
Once the aspnetcirelease feed is stable, we push the packages from it to nuget.org.
Unless you work on developing new features for ASP.NET, I recommend that you use aspnetvnext (for dev bits) or nuget.org (for release bits). The release feed (aspnetrelease) is just a staging feed and it's not always in a good shape.
Edit:
I think it's easier to understand from a table:
I'm abrade that you can get the exact answer on the question only from Microsoft. You can open https://www.myget.org/gallery and filter for "aspnet" for example and will find many other repositories published for different teams.
For me more interesting is the information displayed by .NET Version Manager: dnvm (without parameters):
Thus, for me, the source https://www.myget.org/F/aspnetvnext/api/v2/ (or https://www.myget.org/F/aspnetvnext/api/v3/index.json) is the "official" place for the night builds of ASP.NET 5.
On the other side by filtering of https://www.myget.org/gallery "aspnet" you can see that aspnetvnext contains more distinct packages as aspnetcidev.
It's clear that both repositories probably contains different set of packages.
One important example where the repository https://www.myget.org/gallery/aspnetcidev be used is the new .NET Command Line Interface (.NET CLI) which you find on GitHub here. The new dotnet utility uses https://www.myget.org/F/aspnetcidev/api/v3/index.json together with many other sources in https://github.com/dotnet/cli/blob/master/NuGet.Config.
I suppose that AspNetCIDev is the repository of packages required for .NET CLI. It's the utility, which should replace dnx and dnu in RC2 of ASP.NET 5. See the post, this one and some other.
I am supposed to migrate a website from Sitecore 7.1 to 8.0
I am mainly concerned with Lucene Search and indexing part of search functionality which is to be migrated as well.
I just need a heads-up for errors and bugs for the same and a question (for which no answer was found on web) is that will the search functionality be severely affected by the migration? what care should be taken while migrating?
Any helpful and relevant links are appreciated.
From what comes into my mind, there were certain changes in search configuration
contentSearch/configuration/defaultIndexConfiguration/analyzer
has moved to:
contentSearch/indexConfigurations/defaultLuceneIndexConfiguration/analyzer
there were also changes in ContentSearch namespaces
Also check EncodedNameReplacements setting for media library as it may break some of your links.
If you are using modules - check modules compatibility table by this link https://kb.sitecore.net/articles/541788 as some of them may not yet be available for 8.0. Sitecore.Kernel is now on .NET 4.5 so please keep .NET version updgrade in mind as well
I usually get two clean installations with following versions and check configuration changes in diff tool, where applicable, you may find this practice helpful as well.
Please go carefully through upgrade notes from Sitecore and consider if they have to be performed on your solution. Official upgrade notes to 8.0 can be found here https://dev.sitecore.net/en/Downloads/Sitecore_Experience_Platform/8_0/Sitecore_Experience_Platform_8_0.aspx (but you may need SDN account to access that)
Some other useful references:
https://theagilecoder.wordpress.com/2015/03/09/keystone-considerations-when-upgrading-to-sitecore-7-5-or-sitecore-8/
http://laubplusco.net/quick-tip-upgrading-sitecore-fast-easy/
http://www.velir.com/blog/index.php/2015/06/25/the-art-of-the-sitecore-upgrade/
I downloaded the latest package through Nuget, and installed using the package manager.
Issues:
1) First, I did not see DotNetOpenAuth.OAuth2 in the references. I had to google around like a wild child to get this through another nuget install
2) After doing that, the IAuthorizationServerHost interface is not being recognized.
I am just getting started using DotNetOpenAuth2, but the lack of proper steps and documentation is frankly a turn off. Not everyone using this has built an authorization server before. Any help in getting me up and running is greatly appreciated
If you still want to use NuGet, you can try out DotNetOpenAuth.Ultimate http://nuget.org/packages/DotNetOpenAuth.Ultimate
A single assembly that adds OpenID 1.1/2.0, OAuth 1.0(a)/2.0, & InfoCard authentication and authorization functionality for client and server applications.
PM> Install-Package DotNetOpenAuth.Ultimate
Turns out that downloading it manually, and then adding the dll manually fixes my issues.