After upgrading from NServiceBus 2.0.0.1145 (.net 3.5) to version 2.0.0.1219 (.net 4.0), messages are no longer picked up from the queues when running on a windows 2008 server. Everything works as expected on my dev machine (win 7). Messages are successfully put on the queues, but then nothing happens.
Could this be a permissions issue? If so, I would expect an exception, or at the very least a log entry, but there's no indication that something is wrong.
loadFromRemoteSources enabled=true
and
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
has been added to the config, and I've also tried
useLegacyV2RuntimeActivationPolicy="true"
but no luck.
So nothing shows up in your logs or anything, the messages just sit on the queue?
It appears that it had something to do with the server not being R2. After upgrading to R2, everything works as expected
Related
I have an ASPNET Core project that is running a set of RESTful services using C# and Newtonsoft.JSON 11.0.2 which I incorporated using NuGet. When I run everything locally using Visual Studio 2017 and IIS Express, things work fine and my JSON Deserializer efforts work with no issue.
When I publish the solution in a Web Deploy package and then install that application in IIS 10 on a Windows Server 2016 instance in AWS, the deserializer fails. The error is:
Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: <. Path '', line 0, position 0
It does not matter if I publish in Debug or Release mode.
I ran Postman calls and the JSON being returned is both validate and produces the correct objects. I did see that, in the Solution Explorer, the version is 11.0.2 but in the assets JSON file, the version is pointed to 10.0.1. The .CS project file, when viewed in a text editor outside of Visual Studio, does show 11.0.2.
When I look in the deployed application's folder on the server, I do not see any NewtonSoft DLLs but I do see other NuGet-obtained DLLs. This might not be an issue given how JSON.NET deploys but I thought it was worth mentioning.
I then included a logger and sent the incoming JSON to a file and, again, it all validated as expected.
I have tried everything, ensured CORS is properly implemented both in the application and in IIS. I am at a complete loss as to how to proceed.
Can somebody please help?
Thank you!
I had the same problem and solved by this code in web.config
<system.webServer>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<modules>
<remove name="WebDAVModule" />
</modules>
</system.webServer>
I sometimes browse old question that has no/accepted answers and check if they are still in need of some help, or if something can be done to close the cold case.
This post has already been solved, but the cause and the solution were left only in the comments.
If the first character encountered when parsing is <, you can be sure
that is not JSON. Something is probably sending XML or HTML to your
code in the deployed environment. I would look at that angle. This
doesn't seem like a version conflict to me, otherwise you would be
getting a much different error about not being able to load the file
or assembly. I think this is solely a data problem.
Brian Rogers
#Brian Rogers - Thank you SO MUCH for this last comment. I ended up
opening Production to my development machine and then running
Wireshark to see the communications. Turns out that IIS had "GEWT"
instead of "GET" in the allowed methods web.config for the host
website and I was getting rejections in the cloud instead of the JSON.
Every test I ran which generated output was LocalHost but, of course,
none of the real production work used anything local. Once I fixed
that error, everything worked great!
Ken Tola
#ken-tola, can you please self-answer the question and then accept it to close the case.
I have an ASP .Net Core 2.1 Web API which I've deployed to a new server we recently purchased (running Windows Server 2016 Standard). The API works perfectly on both my development PC and our old server (running Windows Server 2012 R2). But on this new server, I get this error:
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
I remember a year ago also struggling a lot trying to get it to run on our old server. I did eventually get it to work, but I can't remember what I did! Is there any way to get more information on this error? I've checked the Windows Event Viewer on the new server and there is nothing there. Also, although I've got stdoutLogEnabled="true" in my web.config, it's not generating the log - and I've created the \logs\stdout path so the folders do exist...
I've also got app.UseDeveloperExceptionPage(); in my Startup.cs, but I'm not getting any more info that a simple 500 internal server error.
This is what my web.config looks like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\PropWorx.API.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</location>
</configuration>
<!--ProjectGuid: cfa62a1f-c5f6-43f8-bcbe-04068e40b803-->
I've also got the Microsoft .NET Core 2.1.1 - Windows Server Hosting installed and the Microsoft .NET Core Runtime - 2.1.1 installed (both x86 and x64).
Like I said it works on my development PC and on our old server, so it must be a configuration issue on the new server. Is there a way I can get more detailed error information other than just 500 Internal Server Error?
I had an outdated version of the .NET Core Windows Server Hosting bundle. I had version 2.1.1 installed. I removed it, and installed version 2.1.4 and now it works.
Various reasons can cause this issue.
if this is happening only in the browser (working with curl or postman), it can be a pre-flight request error, then you will need to modify UrlScan.ini (I assume this didn't changed on Windows 2016) at the following path (C:\Windows\System32\inetsrv\urlscan), add OPTIONS to [AllowVerbs].
if not, make sure you followed the steps provided in Microsoft documentation:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-2.1&tabs=aspnetcore2x
You may need to install Visual C++ 2015 Redistributable on the server
To get logs, change "IncludeScopes": true, in your appsettings.json logging section, check also the event viewer.
All of a sudden I'm getting an error as follows in Visual Studio:
Error 113 Section or group name 'security' is already defined. Updates to this may only occur at the configuration level where it is defined. myProject\web.config
Here is the section that it is complaining about:-
<sectionGroup name="elmah">
<section name="security" requirePermission="true" type="Elmah.SecuritySectionHandler, Elmah" >
Needless to say the security section only occurs once.
It's like it's checking a cached version of the file somewhere or something.
I had a very similar issue here recently:
Elmah.MVC working under IIS Express but not IIS 7.5
However the solution there does not appear to be working here
OK it turns out this was related to setting MVCBuildViews to true...
Which seemed like a reasonable think to want to do but seems to cause these issues.
I'd be interested still to know a better solution that would allow me to continue to use this flag.
I have a WCF 4.0 service deployed on a 2K8R2 dev server and hosted under IIS 7.5. I'm calling it locally from a test app (WPF). I'm running into a problem sending largish files (via a byte array) where I get the following error when attempting to send a 23MB (or larger) file.
There was no endpoint listening at
http:///FileStorageClone/FileStorage.svc that
could accept the message. This is often caused by an incorrect address
or SOAP action. See InnerException, if present, for more details.
Up to a 19MB works fine. I've upped the timeout settings and set max buffer, received message and array sizes all at 2GB in the web.config file. The exception is thrown almost immediately (not long enough to have timed out).
It's running using basicHttpBinding, though as that's solidified next steps will be other binding types.
I first worked out the connections with small files, then moved to larger. At 64KB I ran into max buffer and received message sizes. At 4MB I learned I needed to bump up the httpRuntime under system.Web from the default 4GB value.
It feels like an IIS or site-level issue to me. Any idea where I may be missing?
It looks like this is a setting more at the IIS level. Setting requestFiltering in the web.config or via appcmd.exe are two viable options. In the web.config, the following example sets the limit to 2.2 billion bytes:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2200000000" />
</requestFiltering>
</security>
</system.webServer>
Thanks to: http://www.dantor.com/support/misc/web-config-requestFiltering-user-agent.aspx
Also, via appcmd.exe, see: http://forums.iis.net/t/1066272.aspx
I am having a problem stepping into code which is a website hosted on IIS7.
Basically I have a test class which calls a WCF service like so
ISecurityService service = new SecurityServiceClient();
MembershipUser membershipUser = null;
membershipUser = service.GetMembershipUser("Mark"); // THIS LINE FAILS!!!
I get the following error but I have everything enabled as far as I know, i.e.
<compilation debug="true" targetFramework="4.0" />
Here is the error msg, I would appreciated any feedback. If I don't try and step into the line above then all works ok.
Microsoft Visual Studio
Unable to automatically step into the server. The remote procedure could not be debugged. This usually indicates that debugging has not been enabled on the server. See help for more information.
dont forget to set compilation debug="true" in your wcf service web.config file.
are you using vista by any chance?
anyways, take a look at this post:
http://mvolo.com/blogs/serverside/archive/2006/12/28/Fix-problems-with-Visual-Studio-F5-debugging-of-ASP.NET-applications-on-IIS7-Vista.aspx
hope it helps
EDIT: have a look here as well
Return MembershipUser using WCF service
You can also try turning on anonymous authentication in IIS. That worked for me when I encountered this issue.
I've had the same error. The problem was that the WCF web service's site on IIS was stopped, because another process was occupying the same port!
To discover what process is, from the command prompt:
netstat -aon | find ":your_iis_web_services_port_number"
Hope this help you.
dont forget to set compilation debug="true" in your wcf service web.config file.
If your startup project different from the WCF Service that is in question and you have start wcf service host when debugging another project in the same solution checked, you will need to set compilation debug="true" in that projects App.config.