I have .net 3.5 app which creates IE9 com object instances.
InternetExplorerClass ie = new InternetExplorerClass();
Unfortunately for me, sometimes the creation of a new object fails with a generic 80004005 error.
I've noticed a similar post here, which however did not put the solution for the IE9 case.
Can you help me with this one? how should i create the ie9 object so that i will not get any more errors?
Thank you,
valentin
Related
I had my working project written in asp.net core 2.1 for a long time, but yesterday, I was forced to upgrade it to .net core 3.0 (due to 2.1 cannot call Dll' s which are written in 3.0 already).
With that, a lot of functions were obsolete or already removed. I fixed almost all of it, but one problem with CORS.
Like many people before me, I used:
app.UseCors(x => x
.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials());
in Configure function. And services.AddCors() in ConfigureServices function.
I was able to fixed this quite easily with setting WithOrigins() or .SetIsOriginAllowed(_ => true) instead of AllowAnyOrigin() which does not work anymore with AllowCredentials().
After that, I was able to start the application and I thought everything is fine, but then I get stuck until now with problem I do not know, how to fix.
I have DB relation N:N and relation table which handle that, that means I have Admin entity with AdminProject list property, then I have AdminProject entity with Admin list and Project list properties and Project entity with AdminProject list property once again.
When I am listing my projects of certain admin, I am returning in Controller this return Ok(projects), where I just use getAll on AdminProject entity and then with Select return only project.
For that, I have to use[JsonIgnore] in project/admin for properties which I do not need to avoid cycling when creating json.
With that said: NOW IN .NET CORE 3.0 AND CORS SETTINGS IT DOES NOT WORK.
I am getting an error:
System.Text.Json.JsonException: A possible object cycle was detected which is not supported. This can either be due to a cycle or if the object depth is larger than the maximum allowed depth of 32.
when debugging in console and error Access to XMLHttpRequest at 'http://localhost:5000/api/project/adminlist/1' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. in WEB browser
I think I tried almost everything with Cors settings etc and I do not know why is this happening now. I also tried to JsonConvert.SerializeObject() before return it ---> return Ok(JsonConvert.SerializeObject(projects)) and this is working, but I am not able (mentally) to do this in every single controllers functions.
Please help! Thanks a lot!
The problem was occurring because in .NET Core 3 they change little bit the JSON politics. Json.Net is not longer supported and if you want to used all Json options, you have to download this Nuget: Microsoft.AspNetCore.Mvc.NewtonsoftJson.
After that in your Startup.cs file change/fix/add line where you are adding MVC (in the ConfigureServices method.
So: here is what I did and what fixed my issue:
services.AddMvc(option => option.EnableEndpointRouting = false)
.SetCompatibilityVersion(CompatibilityVersion.Version_3_0)
.AddNewtonsoftJson(opt => opt.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore);
I hope it will help somebody else.
Cheers!
A couple other things have changed in .net core 3 and now instead of using addMVC you can use addControllers. So your code might look like the follow:
services.AddControllers().AddNewtonsoftJson(x => x.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore);
The parse4cn1 library works well with parse.com but it has some issues when working with Node 4.3.2 and parse-server open source. For example, when calling the ParseUser.signup() function, the "Invalid key name" exception is always happened. I tried to debug and figure out that the ParseCommand object should add the ParseConstants.CONTENT_TYPE_JSON to its header in order to make it can work. I don't why because it still works without doing this with parse.com.
Another issue is the ParseQuery.find() is always failed when using the ParseQuery.whereContainedIn(). The server exception is "ParseException [code=102, msg=Improper encode of parameter, cause=null]". I guess this issue probably regarding the parameter has the json format in this case as well but I don't know to to resolve it. Any advice is appreciate. Sidiabale, do you have any advice? Thanks!
These problems are solved in version 3.0 of parse4cn1. Apparently, Parse Server is stricter with the need to specify the content-type header so code that previously worked with Parse.com does not work with Parse Server. I've addressed these issues in the aforementioned release. Try again with version 3.0 and let me know if you encounter any issues.
I have a production mobile Flex app that uses RemoteObject calls for all data access, and it's working well, except for a new remote call I just added that only fails when running with a release build. The same call works fine when running on the device (iPhone) using debug build. When running with a release build, the result handler is never called (nor is the fault handler called). Viewing the BlazeDS logs in debug mode, the call is received and send back with data. I've narrowed it down to what seems to be a data size issue.
I have targeted one specific data call that returns in the String value a string length of 44kb, which fails (release build). When I do not populate the String value (in server side Java code) on the object (just set it empty string), the result handler is called, and the object is returned, again, using the release build. This works in a debug build.
The custom object being returned in the call is a very a simple object, with getters/setters for simple types boolean, int, String, and one org.23c.dom.Document type. This same object type is used on other other RemoteObject calls (different data) and works fine (release and debug builds). I originally was returning as a Document, but, just to make sure this wasn't the problem, changed the value to be returned to a String, just to rule out XML/Dom issues in serialization.
I don't understand 1) why the release build vs. debug build behavior is different for a RemoteObject call, 2) why the calls work in debug build when sending over a somewhat large (but, not unreasonable) amount of data in a String object, but not in release build.
I have't tried to find out exactly where the failure point in size is, but, not sure that's even relevant, since 44kb isn't an unreasonable size to expect.
By turning on the Debug mode in BlazeDS, I can see the object and it's attributes being serialized and everything looks good there. The calls are received and processed appropriately in BlazeDS for both debug and release build testing.
Anyone have an idea on other things to try to debug/resolve this?
Platform testing is BlazeDS 4, Flashbuilder 4.7, Websphere 8 server, iPhone (iOS 7.1.2). Tried using multiple Flex SDK's 4.12 to the latest 4.13, with no change in behavior.
Thanks!
After a week's worth of debugging, I found the issue.
The Java type returned from the call was defined as ArrayList. Changing it to List resolved the problem.
I'm not sure why ArrayList isn't a valid return type, I've been looking at the Adobe docs, and still can't see why this isn't valid. And, why it works in Debug mode and not in Release build is even stranger. Maybe someone can shed some light on the logic here to me.
In a project WITHOUT the Prism library I had this code working to get a collection of "Persoon" objects:
Dim ObjectCollectie As New ObservableCollection(Of Persoon)()
If MijnAPIResponse.IsSuccessStatusCode Then
Dim AntwoordVanAPI = Await MijnAPIResponse.Content.ReadAsStringAsync
ObjectCollectie = JsonConvert.DeserializeObject(Of ObservableCollection(Of Persoon))(AntwoordVanAPI)
This code refers to a WebAPI to fetch the data and everything works fine.
This same statement won't work in the Prism ViewModel. It goes perfect until the ObjectCollectie is trying to use the JsonConvert statement. The AntwoordVanAPI contains the same JSON string like before.
The error message I get is:
__The API 'System.Collections.ObjectModel.ObservableCollection1[[Dossier365.BusinessModels.Persoon, Dossier365.BusinessModels, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5ff36822ea527de6]]..ctor(System.Collections.Generic.List1[Dossier365.BusinessModels.Persoon])' cannot be used on the current platform. See http://go.microsoft.com/fwlink/?LinkId=248273 for more information.__
This refers to a nonexisting page on the Internet (I have seen more than a few complaints about that!). It is not easy to find anything recent on the subject "API cannot be used". The newest posts were about 2 years old.
Because the code has not changed, I suspect the Prism library. But why? And how to overcome? I have posted this on the CodePlex Prism issuelist as well, but I get the impression that only a few readers are active there. No response for over a week on issues. I hope StackOverflow does a better job.
Please, PLEASE, anyone knows an answer to this??
Peter
After a couple of hours of comparning the code and about everything else, I finally figured out that the cause of this error lies in JSON.Net version 6.0.4. After stepping back to JSON.Net version 6.0.3 everything worked perfectly again. I have reported this in the JSON project on CodePlex.
I'm using the WkHtmlToXSharp wrapper library in my project to generate PDF file from HTML.
I was using this library a lot of times in different PCs and, suddenly, I came across the following problem:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at WkHtmlToXSharp.WkHtmlToPdfConverter.wkhtmltopdf_convert(IntPtr converter)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert(String inputHtml)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert()
at WkHtmlToXSharp.MultiplexingConverter.b_8()
--- End of inner exception stack trace ---
at Sanford.Threading.DelegateQueue.EndInvoke(IAsyncResult result)
at Sanford.Threading.DelegateQueue.Invoke(Delegate method, Object[] args)
at WkHtmlToXSharp.MultiplexingConverter.Convert()
This seems to be a common problem with this library (I've found some feedback on the web about it - however no fix was provided). BTW, in my case it happens somewhat randomly. I was not experiencing this problem in other dev machines. I wonder if somebody has a fix for it. I also wonder if this is a problem with the wrapper library, if with the WkHtmlToPDF library itself.
Any suggestion? I'm also open to use another converter, as long as it is free and stable and, if possible, without spawning a new process. It must work properly and stable in all Windows versions and do a decent job converting (the HTML to be converted is fixed - contains a few pics and tables and basic CSS).
I would suggest an alternate route: simply use wkhtmltopdf.exe directly, building your own wrapper. They are not very complicated if you have control of the input and then you know exactly how to update it and how the options work. I've never encountered with that problem when using wkhtmltopdf directly (on Win7, Win server 2008 r2, Ubuntu and CentOS). They do spawn process for every conversion though.
For an example, check out the Derp class in another answer of mine regarding wkhtmltopdf. Or try something like the untested code below (your true code will be more complicated, this is just a demo/POC).
var pi = new ProcessStartInfo(#"c:\wkhtmltopdf\wkhtmltopdf.exe");
pi.CreateNoWindow = true;
pi.UseShellExecute = false;
pi.WorkingDirectory = #"c:\wkhtmltopdf\";
pi.Arguments = "http://www.google.com gogl.pdf";
using (var process = Process.Start(pi))
{
process.WaitForExit(99999);
Debug.WriteLine(process.ExitCode);
}