One of the endpoints of the API that I work on contains an optional nullable parameter provided by query string.
The endpoint is defined similar to the following example:
[HttpGet]
[Route("nullable")]
public IHttpActionResult GetAnonymousTypeDefinition([FromUri]long? i = null)
{
return Ok();
}
A contrived and functionally useless example I admit. However, when I run this example locally and in my "dev" environment, it returns 200. However, when this code is run in my "test" environment it returns a 500 and I'm provided the following error:
Could not load type 'System.Nullable`1' from assembly 'Example.API,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
Just to ensure that my test environment was running a version of the framework that has support for nullable types, I added another endpoint that returns Environment.Version, like so:
[HttpGet]
[Route("framework-version")]
public IHttpActionResult GetFrameworkVersion()
{
return Ok($"{Environment.Version}");
}
The above endpoint returns the following value:
"4.0.30319.42000"
At this point I'm kind of at a loss as to what else I should check.
Any thoughts?
Indeed, there was an issue with how Instana's IL-rewriting process handles Nullable<T>. We provided a quick fix as soon as we were aware of the problem and knew what happened.
This being said I strongly recommend contacting our support-team to get a quick response and let us know about any issues with our components.
The fix has been confirmed and will be released within the next 24 hours.
If you want to get the fix prior to that, contact the support-team and we will provide the patch to your team.
It turns out that we were evaluating Instana in our test environment.
One of our ops guys did the following:
Uninstalled the Instana agent and rebooted, then...
Removed Instana related registry keys from:
hklm/software/Microsoft/Fusion/GACChangeNotfification/default
hklm/software/microsoft/tracing/instana*
hklm/software/wow6432Node/microsoft/tracing/instana*
And unregistered the following DLLs:
regsvr32 /u "C:\Program Files (x86)\Instana\instana-agent\data\repo\com\instana\agent-windows-extensions\1.3.1\agent-windows-extensions-1.3.1\tracing\Instana.Profiler_x86.dll"
regsvr32 /u "C:\Program Files (x86)\Instana\instana-agent\data\repo\com\instana\agent-windows-extensions\1.3.1\agent-windows-extensions-1.3.1\tracing\Instana.Profiler_x64.dll"
We had the same problem with Instana. This afternoon we received two new dll's for the Instana agent. After replacing these and restarted the agent everything started to work again. Instana will release a new version of the agent that fixes this issue.
Related
Client company just upgraded to 2016 from 2011. I've been testing the plugins to make sure they all still function and I've finally (after much frustration) figured out what is happening, but no idea why or how to resolve this.
I have several plugins and they all function exactly as expected - as long as the updates to the data are not run through the forms.
Let me explain:
I have plugins (Synchronous) that trigger on a change to a field. If the field is changed via a workflow, or some other coded process, everything runs just fine.
But when I update the field on the form it's self. It fails with a very generic error (below).
I support a couple of other clients already on 2016, and I'm not experiencing this same problem. So I'm not even sure where to begin. I've been going crazy here the last couple of days to check the code. But it only happens when updating the field on the form. Every other method of updating the data that I have tested works with no errors.
I also have another issue. When the field is updated (through a test workflow), it runs and updates a child record. The child record then has a workflow that runs to deactivate the record. The workflow says it ran and deactivated the record, but it never deactivates).
Anyway. if ANYONE has ANY idea at all about what could be causing this. I would love to hear it. I'm at my wits end on this.
Thank you in advance.
I've tested the code and had it run successfully, as long as I don't update the field through the form. To test this I created some test workflows that update the data, they successfully run and the plugins fire off with no problems.
EntityReference contact =
(EntityReference)preImageEntity.Attributes["ipmahr_contact"];
QueryExpression cn = new QueryExpression("ipmahr_recertification");
cn.ColumnSet = new ColumnSet("ipmahr_contact", "statecode");
cn.Criteria.AddCondition("ipmahr_contact", ConditionOperator.Equal,
contact.Id);
cn.Criteria.AddCondition("statecode", ConditionOperator.Equal, 0);
EntityCollection results1 = server.RetrieveMultiple(cn);
if (results1.Entities.Count > 0)
foreach (Entity a in results1.Entities)
{
a.Attributes["ipmahr_deactivaterecertificationrecord"] = true;
server.Update(a);
}
The code is pretty straightforward in most cases, and works fine as long as things aren't updated on the form.
Here is the error: Exception: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: System.ServiceModel.CommunicationObjectFaultedException: #595EB751 (Fault Detail is equal to Microsoft.Xrm.Sdk.OrganizationServiceFault)., Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af Exiting Recertifications.Main.DeactivateUsedRecertificationsonEndDateChange.Execute(), Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af
New information. I have found that not all the plugins I've written have an issue on this server. This is good. But I also found that there is a commonality on those plugins that do fail.
Any plugin using a Query Expression fails with the generic error. Adding robust error checking didn't show anything (once error checking was added, it just didn't run anything, and didn't produce any errors in the logs). Trace logs didn't show anything significant either.
So now I'm wondering if there is something in the way the Query Expression is formatted, or if there is an issue with the SQL. I mention SQL because I found this morning that if I create fields too fast, I get a generic SQL error. Wait a minute and I can create new fields without a problem.
I think it likely that this plugin is not actually failing based on the error you are receiving and the fact that it happens conditionally. More likely, your server.Update(a); call is resulting in a failure within a secondary plugin or workflow action triggered by update of the Recertification record.
- Comment out that line and verify that the plugin works
- See if you can reproduce a failure by directly updating that field on the Recertification record
- Review plugin/workflows running against the Recertification entity
Most likely this has one of the following root causes:
- A security issue based on different executing users between the form update or workflow update
- Other tangential fields are being updated by one or the other of those two methods which subsequently cause different behavior in a secondary plugin/workflow
Over HTTP and inside of Visual Studio it is working fine. However, when I attempt to hit the endpoint over HTTPS I'm seeing this error and I'm not entirely sure how to figure out the problem:
info: Microsoft.AspNetCore.Server.Kestrel[17]
Connection id "0HL36O0ESIPBQ" bad request data: "Invalid request line: <0x16><0x03><0x01><0x00><0x83><0x01><0x00><0x00><0x7F><0x03><0x01>X<0xC1><0x07><0xDC><0x9E>~Y<0x05><0x13><0xC1><0xF4>^J<0xCF><0xAB><0x11><0xC3>R[<0x87><0x1D>..."Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException: Invalid request line: <0x16><0x03><0x01><0x00><0x83><0x01><0x00><0x00><0x7F><0x03><0x01>X<0xC1><0x07><0xDC><0x9E>~Y<0x05><0x13><0xC1><0xF4>^J<0xCF><0xAB><0x11><0xC3>R[<0x87><0x1D>
Fiddler gives me this:
System.IO.IOException The handshake failed due to an unexpected packet format.
My gut tells me this has to do with moving from dotnet core 1.0.1 to 1.1.0. This was all working fine before that point, but it is equally likely I screwed something else up and I'm just not sure what! :)
I'll add to Paul's hint in the form of an answer.
The .UseHttps class is in the "Microsoft.AspNetCore.Server.Kestrel.Https" module, which can be added by searching for "usehttps" in the Package Manager UI or by adding it to your project.json file. Note that at the time of this writing, version 1.1.1 is now available for ASP.NET Core, so be sure to choose the version you need.
Not sure it will solve my problem, but perhaps it will solve the problem of someone else that reads this.
Ok. I'll answer my own question. It turns out I just needed to add .UseHttps to my WebHostBuilder in program.cs:
.UseKestrel(options =>
{
options.AddServerHeader = false;
options.UseHttps("MyPfx", "MyPassword");
})
I guess I'm a little confused how this was working previously without this but hey, it works now!
I am working on a project that includes an ASP.NET WebAPI component.
Intermittently, I get the following error:
Could not load type
'System.Net.Http.Formatting.FormUrlEncodedMediaTypeFormatter' from
assembly 'System.Net.Http.Formatting, Version=5.2.3.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
with the source error pointing to my GlobalConfiguration.Configure() call:
Line 35: {
Line 36: AreaRegistration.RegisterAllAreas();
Line 37: GlobalConfiguration.Configure(WebApiConfig.Register); //<-- error here
Line 38: FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
Line 39: RouteConfig.RegisterRoutes(RouteTable.Routes);
In my register, I am doing the following to return JSON by default:
var appXmlType = config.Formatters.XmlFormatter.SupportedMediaTypes
.FirstOrDefault(t => t.MediaType == "application/xml");
if (appXmlType != null)
{
config.Formatters.XmlFormatter.SupportedMediaTypes.Remove(appXmlType);
}
(not sure of the source, but found somewhere on this site as a way to return JSON by default, unless the caller asks for something else)
I'd like to continue to return JSON as the default content type going forward.
The project includes two other (non WebAPI) websites (that are MVC5), which hit the WebAPI site.
Here's the interesting thing:
This DOES NOT happen when the application is deployed (to Azure)
This only happens occasionally
Typically, I run one of the MVC5 sites in the debugger and see this issue
If I navigate directly to the WebAPI site after the above, I'll get the "Yellow Screen of Death" with the error as per above
Sometimes, even after a cold reboot, this error will NOT appear, other times it will
What I currently do to work around the problem:
If I run the WebAPI site in the debugger, if the error is present, it will fixed itself
After running in the debugger (per above), I can relaunch an MVC5 site in the debugger and the issue goes away
Just to repeat, this DOES NOT happen ever when the application is deployed to Azure.
I have multiple developers working on this project, and we all run into the same error at some stage.
I am referencing the following Nuget packages:
Microsoft.AspNet.WebApi (version 5.2.3)
Microsoft.AspNet.WebApi.Client (version 5.2.3)
Microsoft.AspNet.WebApi.Core (version 5.2.3)
Microsoft.AspNet.WebApi.Owin (version 5.2.2)
Microsoft.AspNet.WebApi.WebHost (version 5.2.3)
If I look inside the *.csproj file, I have a reference to the following:
<Reference Include="System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll</HintPath>
<Private>True</Private>
</Reference>
I've checked the bin folder of the website, and all the assemblies inside it have the correct version as per the above list (including System.Net.Http.Formatting.dll).
Also note that, during debugging and development, each of the three websites are run under Local IIS (constraints of external resources force us to do this), so I have:
http://localhost/site1
http://localhost/site2
http://localhost/api
It's becoming cumbersome to get into a debugging session, to get this error, to then stop debugging, launch the API site under the debugger, and to then switch back to what I was doing at the start.
Not sure where else to go to track down what is happening here. Any ideas?
Update - 26 July 2016
Still have this happening. Since posting the question, have updated the WebAPI to run in its own Application Pool, but that doesn't seem to have made a difference.
Uninstalled Web API 2 NuGet package
Installed Web API 2 NuGet package again.
I think you are going about it wrong. Try setting JSON as your default media formatter like this:
// first clear all formatters
config.Formatters.Clear();
// Since JSON is the first added,
// it will be the "default" if no Accept header present
config.Formatters.Add(new JsonMediaTypeFormatter());
// You can choose not to add these back if you never want to use them,
// up to you.
config.Formatters.Add(new XmlMediaTypeFormatter());
config.Formatters.Add(new FormUrlEncodedMediaTypeFormatter());
I had added what was possibly an incorrect version of System.Net.Http.Formatting to my Global Assembly Cache (GAC) and started getting
Could not load type
'System.Net.Http.Formatting.FormUrlEncodedMediaTypeFormatter' from assembly
'System.Net.Http.Formatting
errors in my Webservice. After removing this System.Net.Http.Formatting dll from GAC my webservice started working again.
when you build looks for any warning that talks about conflict. Double-clicking on the warnings injects the compatible versions in the section of web.config. This obviously can be done manually also.
I am developing a RESTful web api service. It's web api v.1, not v.2. Also I am developing on Visual Studio 2010 SP1. I have installed the MVC 4 for VS2010 SP1.
Please understand and keep in mind that Upgrading to newer versions of VS or Web Api 2 is not an option.
I have the following problem after a Windows Update ocurred.
When I try to use my RESTful api this way....
http://url.com/documents/ (get all the documents) I get the following error...
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Here is the stack trace.
[HttpException]: File does not exist. at System.Web.StaticFileHandler.GetFileInfo(String virtualPathWithPathInfo, String physicalPath, HttpResponse response) at System.Web.StaticFileHandler.ProcessRequestInternal(HttpContext context, String overrideVirtualPath) at System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state) at system.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
If I specify the action name directly, it works. For example...
http://url.com/documents/get (gets all the documents) or
http://url.com/documents/7 (gets document id=7.
It only fails when you call it by its default name. I have already read similar situations here and I have tried to follow their solutions but they are not working for me properly.
Now, I know this is not a "web api routing" issue because I actually get the .net default exception page html markup (I am using Postman to test my webservice). When I force a "routing issue", then I get a JSON error description, which means that the Controller actually got created in the pipeline and returned a response.
Also, I have a custom file (SecurityHandler) that inherits from DelegatingHandler. This file gets executed almost first in the pipeline with each call to the api. Even before the actual Controller. Well, this file is never called when I get the error, which confirms to me that the "webserver" (either VS Development Server or IIS 7) is the one throwing the exception.
I have exhausted every single solution that I have found here. Change my web.config to multiple handlers configurations, re-installed MVC 4 for VS2010, created an entire new project... all these efforts have shown no results whatsoever.
Like I said, this was working perfectly fine until my pc restarted from a Windows Update BUT... why does it fail in the server as well? I did deploy my api to the server after the error started to occur.
Thanks.
The issue is not in Web API (and has nothing to do with it's version or Visual Studio 2010), it's the static file handler trying to serve and failing.
Alternatives:
0. Do you have a documents folder in your site? Get rid of it.
1. Remove the static file handler for directory browsing and re-add it.
2. Use RAMMFAR (less recommended)
I have been trying to get Google Cloud Messaging to work in eclipse. I was able to compile the example given on their demo webpage and run that without any errors; however, when I try to create my own example using jersey I get the run time error "java.lang.NoClassDefFoundError: com/google/android/gcm/server/Sender" when the following code tries to create a sender.
#POST
#Path("/send")
public Response sendMessage() throws IOException
{
Sender sender = new Sender("api_key");
Message message = new Message.Builder().build();
sender.send(message, DataStore.getDevices(), 5);
return Response.status(200).entity("Success").build();
}
Note: I have replaced my real api key with api_key. I know it works because I was able to get the demo working by running the ant commands explained in the tutorial. Also just to be specific in case of ambiguity, the error I am getting is server side, and has nothing to do with the android device.
Things I have already tried:
I have included the gcm-server.jar in my WEB-INF/lib folder and under project properties I have included it in the build path.
I have also tried, as mentioned on other sites, to include json_simple-1.1.jar the same way I included gcm-server.jar. I don't see how this would effect this error but I saw this listed as an answer in a few different places.
(Solution) Deleted the tomcat server and created a new one. I probably could have just cleaned the project instead and had the same results.
Demo tutorial link: http://developer.android.com/guide/google/gcm/demo.html.
I just found a solution to my problem. In frustration I deleted the old Tomcat server from eclipse and created a new one. When I ran the project again there weren't any problems at all. When I first set up the project I had included the jar files in WEB-INF/lib and later, after reading a lot of posts on the internet, added gcm-server.jar to the build path. It appears that this action would have fixed it but for some reason unknown to me there were some left over files on the server from before the change. I should have tried cleaning my project but I didn't even think about that being the issue. Anyway, I hope that this helps someone because I've sort of condensed all of the information I could find on the internet into this post, as well as included my own dilemma and solution to it.