Yesterday the version 3.9.0 for the SAP Cloud SDK was released including the OData VDM Generator. However the corresponding Maven Plugin is still missing. Is there some reason for this or when can we expect this to be released? After all it contains an important bugfix.
Version 3.9.0 of the plugin should also be available since Thursday, like the other artifacts, see https://search.maven.org/artifact/com.sap.cloud.sdk.datamodel/odata-generator-maven-plugin/3.9.0/maven-plugin
The indexing on Maven Central may sometimes take a bit longer, perhaps this is what you experienced. Please recheck if the issue persists.
Related
Why is 3.2.0 not available here any more? https://downloads.apache.org/spark/
Just to be clear, it was here until a few days ago. This link is checked into our internal repo. Realized this artifact is no longer available when the build broke.
Need to make sure we don't go to prod with this version if there is any known major issue with it that caused it to be taken down.
Download Spark page has only the latest version of every major version of Spark. If you want a specific version not listed on the main downloads page, you can use Archived libraries link.
I've got an Azure Function app that creates a precompiled DLL (so it uses normal .cs files, not the older .csx method, pre-VS2017). Previously, it was targeting .Net Framework 4.5.2. I updated it to 4.7 so as to use some of the new C# 7 features. I updated my NuGet packages by doing "Update-Package -Reinstall" and verified that they all have the "net47" target set in my packages.config file.
Everything compiles fine. But when I call a function that uses either of 2 HttpRequestMessageExtensions methods, I get an exception. One example of the exception is this:
Method not found: 'System.Net.Http.HttpResponseMessage
System.Net.Http.HttpRequestMessageExtensions.CreateResponse(
System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode)'.
Here's an example of a tiny test function that will cause the error:
using System.Net;
using System.Net.Http;
public static HttpResponseMessage Run(HttpRequestMessage req)
{
return req.CreateResponse(HttpStatusCode.Accepted, "");
}
Upon calling this function with say Postman, I'll receive the aforementioned exception. I also get a similar method not found exception when I call GetQueryNameValuePairs() on the HttpRequestMessage.
I've tried updating my NuGet packages to the latest, no difference. I've cleaned and rebuilt and restarted a bunch of times, making sure to nuke my bin and obj directories.
I'm not sure what could be the problem. I guess I could downgrade back to .Net 4.5.2 but I'd rather not. For one, I want to use C# 7, and for two, I want to understand what the problem is rather than avoid it.
Update: interesting. The issue seems to be with System.Net.Http. If I lower it to 4.0.0 everything works fine. If I raise it to any higher version I get the issues listed above. I tried selectively lowering each of my packages, one by one, to their previous version number to find this out. I then updated all but this one to the latest version and it fixed the issue.
I also tested it on my side. The issue is related to the latest version of System.Net.Http assembly(4.3.2). If I don't install this package manually or install the earlier versions(4.3.1/4.3.0), the application could work fine.
The CreateResponse method is a extension method which is written in System.Web.Http assembly(version 5.2.3). It seem that it is not compatible with the latest version of System.Net.Http. Please could just skip the error by using the earlier version of System.Net.Http and you can also submit this issue to Microsoft using follow channel.
https://connect.microsoft.com/VisualStudio/Feedback
Interesting. For me, if I got above version 4.0.0 (including 4.1.1 or 4.3.1) I still get the same problem of not finding those extension methods.
The assembly might not be updated during you change the package version. From the bin\Debug\net47 folder, we could check the current assembly version we used.
If the modified date of assembly is 2/9/2017, the package version is 4.3.1. If the modified date of assembly is 4/19/2017, the package version is 4.3.2. If the assembly is not the latest version, it could work fine on my side.
In addition, Microsoft.Asp.Net.WebApi.Client package is installed by default when creating an Azure function. System.Net.Http is one of its dependencies. So we don't need to install the System.Net.Http package manually. When running our application, NuGet will choose a right version of System.Net.Http for our application.
I had the same issue running my Azure Function locally and eventually tracked it down to conflicting System.Net.Http assemblies. I created my Azure function from a blank ASP.NET Web App and initially pulled down the System.Net.Http NuGet package to use within the project. I also pulled down the Microsoft.AspNet.WebApi.Client for use within the project. It did not matter which version of System.Net.Http I tried my project would compile but fail when the request was made.
Eventually, I removed packages I had downloaded, cleaned the build folder and added just the Microsoft.AspNet.WebApi.Client. I noticed that this automatically referenced the System.Net.Http on my machine for my version of the .NET Framework. (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework). This compiled successfully and I was able to make requests to the function without any exceptions.
Using #Aaron-Newton's insight, I identified that my issue was due to my Azure Functions project referencing a .Net Standard 2.0 class library. I switched it to .Net Framework 4.6 and it started working again. Seems like this is a bug in the Functions tooling.
I've filed a bug with the Functions team here: https://github.com/Azure/Azure-Functions/issues/477
I had the same issue. I spent quite a while to fix this problem.
The cause is that the Azure Functions project is refering to .Net Standard Library with version higher than 1.4.
Bringing down your .Net Standard version to 1.4 or lower would fix the problem.
But this is defintely a bug with Azure Functions SDK. They should fix it.
https://github.com/Azure/azure-webjobs-sdk-script/issues/980
https://github.com/Azure/Azure-Functions/issues/477
To convince my employers of the benefits of ANTLR and StringTemplate, I constructed a small demonstration first in Java. But Java is not one of our preferred languages, so I translated it to C#. Using VS2015 (Community Edition) and various instructions on the net I got only so far. I now get
ANTLR cannot generate 'org.antlr.v4.codegen.CSharp_v4_5_2Target' code as of version 4.3
Incompatible versions? Which versions of what libraries are compatible for a successful build. I could not work out how to use GitHub. There didn't seem to be a package to download, and I could not see how to download a set of files to compile.
Update 1
Randomly installing versions of whatever I can find, I have now got it down to loads of errors like this from the generated code.
CS0103 The name '_errHandler' does not exist in the current context
Update 2
I have subsequently tried (and failed) to get it going in VS2010(Express). I think that version is seriously hobbled. I can't get NuGet working on it. I am now going to try to install VS2013 as that seems to be the most commonly referred to in this ANTLR context. With VS2015 I have been through all the .NET versions I have installed on my machine back to v3, with no success. It now fails to generate the parsing code.
Update 3 - Solved
Problem solved! Use VS2013 and follow Sam Harwell's clear instructions. Some minor differences between Java and C# to work out when using StringTemplate
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.
How do I get the source for a specifik stable release of servicestack from Github?
I'm trying to download and build the source for version 3.9.0.0 but I am having two sorts of problems.
1) There are no labels for the main service stack project so I can't figure out at what commit the 3.9.0.0 was built from.
2) Since Service Stack main project depends on ServiceStack.Text I also need to know against what version of ServiceStack.Text the ServiceStack 3.9.0.0 was built against.
If anyone wonders. The reason I ask this is because the later ServiceStack releases are not all backward compatible and a project I recently took over is throwing exceptions down in the ServiceStack.Text. And the version of ServiceStack.Text seems important since the version of ServiceStack and ServiceStack.Text I downloade, collided on build on extension.
The state I am at is that I got souce for what seems to be 3.9.4 and I managed to get hold of a nuget packet of ServiceStack.Text with version 3.9.0.0 that I could compile against (no source) and this actuallt killed of the trubbeling exception in ServiceStack.Text so that problem seems at least temporarely solved. At the next issue I'll probably be stuck again so I'd really like the source. (It is the point with open source after all right?)
Best regards, Nick
Although older versions are not supported by ServiceStack, you could to go back through the ServiceStack commit logs until you see a message that says INCR to v3.9.x.
One way to quickly browse releases is to look at changes to the Properties/Assembly.cs file which changes when the version is incremented.
As ServiceStack is uses components from different sub projects, you will need to do the same for ServiceStack.Text, ServiceStack.OrmLite and ServiceStack.Redis as well.
ServiceStack keeps the same version in-sync with the other components, so the v3.9.4 of ServiceStack uses a v3.9.4 of ServiceStack.Text, etc.