I've downloaded the .NET xAPI from here: https://github.com/RusticiSoftware/TinCanAPILibraryCSharp
When I test the code in console mode I am able to make a connection with both my local server and public lrs: http://tincanapi.com/public-lrs/
However, when I run that same code from Unity, I can only make a connection with my local server, I can no longer connect with the public lrs or any other remote server for that matter, I keep getting "no internet connection" and nothing else.
Any ideas on what this could be??
Currently and if i m right, running dlls compiled with .NET frameworks > 3.5 on unity3d can be a problem. Considering tin can is newly released... Maybe your problem is related?
If you create the dll yourself, be sure to focus on .Net framework 3.5
Related
I have attempting to upgrade a web application that uses .NET Framework 4.5 to 4.8.
The application runs on a server that both compiles and runs the application, so I installed the .NET Framework 4.8 Developer Pack. I restarted the server and it has booted up successfully.
TeamCity successfully built and compiled the application and Octopus successfully deployed as per usual. However, when I now attempt to access the website, I get a 404 at the login page.
Looking at the folder structure, the file is definitely there. The code builds and runs successfully on my local machine, allowing me to login and perform any function on the system.
Is there something that I have missed running or doing on the server to get this to work?
Edit: Request for IIS Configuration
The configuration of this hasn't changed since I've upgrade the .NET Framework but here is what I have. If this isn't the configuration that is being asked about, please let me know.
Bindings
Everything else has been left as the default values.
I have created a DLL [made available as a NuGet package (.NetStandard 2.0/2.1)].
When a particular class in this DLL is instantiated, we fire an synchronous GET call to a .Net Core WebAPI installed on IIS on my local machine (localhost) to load some configuration data.
This DLL makes use of a singleton HttpClient (we've following Microsoft's 'best practices' here)
Factory.SingletonHttpClient().GetAsync(args.Uri).GetAwaiter().GetResult();
I've consumed this NuGet package in a whole series of applications, all built using .Net Framework 4.7.2 and they work just fine - the data is successfully retrieved from the WebAPI.
However....I have one particular application (again, 4.7.2) where the GET consistently fails with the error message:
System.Net.Sockets.SocketException HResult=0x80004005 Message=An
existing connection was forcibly closed by the remote host
This exception was originally thrown at this call stack:
System.Net.Sockets.Socket.BeginReceive(byte[], int, int, System.Net.Sockets.SocketFlags, System.AsyncCallback, object)
So this has to be something specific to my application that consumes this NuGet package since it works for all other consuming applications. However, I can't see how to figure out what the problem might be.
So I found the answer, but I'm confused by it.
I'm using the latest version of Windows 10 (version 1909).
All my applications are using .Net 4.7.2
So when I debug all these .NET 4.7.2 applications on my machine, they all make the call to the WebAPI on my IIS LocalHost, except this one application.
When I look at the ServicePointManager.SecurityProtocol in this failing application, I see it's running with the obsolete values of SSL and TLS. Why would this be the case for this application but not the others? It's not stipulated anywhere to use these obsolete protocols, so why is this using them but not the other applications?
I fixed this by amending my NuGet DLL to add TLS1.2 to whatever TLS versions are being used:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | ServicePointManager.SecurityProtocol;
I'm recently going through my first Kentico upgrade on a site that was previously handed to me from somebody else. There were some hinks initially, but I have to say the V8.2 to V9.0 upgrade is gone off with a degree of success. There is one last issue I'm tackling. Initially the issue was with images stored in the database, but I resolved that with setting custom URL extensions. The style sheet we have in the database is returning a 404, so the entire site is without style.
I did some digging, and found the following:
While we were using ~/CMSPages/GetCSS.aspx in V8.2, that appears to have been deprecated/obsolete for some time now. The CSS references in the master page all point to ~/CMSPages/GetCSS.aspx.
In V8.2, I can confirm the presence of ~/CMSPages/GetResource.ashx, but that appears to be missing after the V9.0 upgrade. I installed a blank template site as well to confirm, and it's not there either. I verified I am using the latest upgrade package. I had already hit an issue with the pre-12/15 edition.
The V8.2 ~/CMSPages/GetResource.ashx does not work in a V9.0 as the API for CMS.UIControls no longer contains the ResourceHandler class (which is also used in ~/CMSPages/GetCSS.aspx).
I can confirm in the V8.2 codebase that ~/CMSPages/GetResource.ashx works, returning the specified stylesheet.
TL;DR - Upgrading from V8.2 to V9.0, I appear to be missing ~/CMSPages/GetResource.ashx, and am not sure where it got off to.
Environment Information
Test Server: Windows Server 2008R2 SP1 on IIS 7.5 w/ .NET 4.5.2, MSSQL 2008R2 Database backend
Dev Server: Windows 8.1 with IIS 8.5, VS 2015 and MSSQL 2008R2
Kentico V8.2 Site in Portal Mode
I appreciate any ideas you have.
Thanks!
Most of the .ashx were moved to the CMS.UIControls assembly and adjusted to implement IHttpHandler.
This way the handlers can be used by any application that references the Kentico libraries, specifically the UIControls. This approach has been utilized e.g. in the new MVC support in Kentico 9.
If you need to customize the handlers you can take advantage of the GetFileHandler and AdvancedGetFileHandler abstract classes implementing IHttpHandler.
I was receiving a 404 on GetResource.ashx in v8 when deploying my site. I have my site setup as a web application. My problem was I was only deploying CMSApp using Visual Studio. I needed to also deploy CMSApp_AppCode. https://docs.kentico.com/display/K81/Publishing+web+application+projects+from+Visual+Studio
when I upgraded to v9 from v8.2 I was getting a 500 Error on GetResource.ashx. After my upgrade I just re-deployed. I don't know what the issue was, but getting the errors, I cleared out all the files on the Azure server then deployed. This fixed my error.
Maybe one of these two items will help you.
If I read the release notes correctly, they moved the files to the UIControls library and you can still utilize the old references without issue. I've upgraded my website from 8.0.48 to 9.0.1 and 9.0.4 and had no issues. In fact, I still use the /CMSPages/GetResource.ashx?scriptfile=/path/to/file.js I believe the change was specifically to accommodate the MVC model.
I'm trying to run some service and I'm getting this message
Method not found: 'Void System.GC.Collect(Int32,
System.GCCollectionMode)'
I suspect the server because this service runs on other servers.
I really want to know what the source of this problem because I came across this problem on other servers.
I try to take of code from my service and finally I realized that even I run a console application with only one static main and call the GC I get this error,
I'm using Windows Server 2003 with Framework 2.0 and 3.5
When you create your console application make sure your target framework is not set to Client Profile FrameWork 3.5.
The above setting is in Application tab of your project properties
If you want to use GCCollectionMode and Framework 2.0 you will have to install .NET 2.0 Service Pack 1
We developed an web application using visual studio 2008. In my development PC, the application is working fine. In production server I am getting the following exception "ASP.NET AJAX CLIENT FRAMEWORK FAILED TO LOAD". What should I do to make it work?
Thanks,
P.Gopalakrishnan.
I'd start with making sure all of the appropriate service packs are applied and that the 3.5 framework is actually installed on the box.
Also, make sure any assembly you reference that isn't part of your deployment is gac'd on the machine. Check version numbers.
All else being equal, I'd guess the server is just way out of date on it's updates.