I am currently trying to setup code analysis for a legacy WPF application. As part of this I am running FxCop 10.0 but I'm receiving errors for some of my DLLs, all of which build successfully.
The error that I'm getting is:
When I get this it is usually on a get or set property, there doesn't seem to be anything obvious as to why this is happening. I can't seem to be able to recreate this in a sample application. An example of a section of code causing this error within a set is:
Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Normal, new Action(() =>
{
OnPropertyChanged("MyProperty");
}));
In the above code, if I remove the Dispatcher code FxCop successfully analyses the code, however leaving it in causes an error to be thrown. There are other instances of similar code working fine. Does anyone have any idea as to what could be causing this error?
Related
Our application is using CefSharp version 73.1.130. The issue only occurs on a small number of internal workstations within our organization. Worth noting, we are also seeing the same error with CefSharp version 92. Another strange thing is that it the issue is consistent, but only when the web apps are launched through certain navigations. Other navigations work consistently for these users.
We use RegisterJsObject to register a javascript object with browser. If I understand correctly, asynchronous binding is preferred moving forward.
The issue presents as strange/unexpected behavior in the hosted web application due to failure to retrieve context from the host WinForms application. The behavior would suggest a failure to register/bind the js object with the RegisterJsObject method. However, that method is not throwing an exception.
Enabled Cef logging showed the following error:
ERROR:JavascriptRootObjectWrapper.cpp(34)] IBrowserProcess is null, unable to bind object
After looking into the code, it appears the location that the value pointed to by "IBrowserProcess" is set is in WcfEnabledSubProcess::OnBrowserCreated (https://github.com/cefsharp/CefSharp/blob/cefsharp/73/CefSharp.BrowserSubprocess.Core/WcfEnabledSubProcess.cpp). I was able to build CefSharp and add additional logging to that method.
On my workstation (I'm not affected by the issue), I get through OnBrowserCreated with no exceptions. However, on my coworkers workstation I see the following line is failing:
...
channelFactory->Open();
auto browserProcess = channelFactory->CreateChannel();
auto clientChannel = ((IClientChannel^)browserProcess);
try
{
clientChannel->Open(); <-- FAILS
browser->ChannelFactory = channelFactory;
browser->BrowserProcess = browserProcess;
}
catch (Exception^)
{
}
}
With the error:
There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)
Has anyone seen this issue before? I'm not sure how much this will help, but does anyone know if it's possible to enable WCF tracing with the CefSharp.BrowserSubProcess.exe. I have been trying this, but no luck so far.
require(["dojo/i18n!myapp/nls/extTools_i18nStrings"],function(extTools_i18nStrings){
// Do something with the loaded file
});
If the resource file (extTools_i18nStrings) has syntax error, it will be shown in dojo.js. How can I handle it in my code?
Try catch block did not work.
Thanks in advance.
Error: Script error .............dojo.js:15
The quick answer is you don't want to. The right thing to do is fix the bundle. This is the same as having errors in your application code, and you would not expect the code to 'handle' that.
But since i18n is an AMD plugin running as part of the loader (which is why you can't try/catch it), the error might be reported through the AMD micro event API, and you could use that to show a better error. I'm not sure how you 'handle' this syntax error other than showing an error.
If you can't control the quality of the bundles via some part of your development or build process you'd have to invent your own alternative to dojo/i18n and you probably don't want to go down that route for all of your bundles.
I am suddenly getting the error: "Unable to locate persister for the entity named 'MyLib.Project'."
I did not make any code changes to this project since the last time I published it. The reason I went into the code to look at it is because a user reported that the web page that utilizes this library was giving an error. I have also checked the eager loading of the provider as per (NHibernate - Random occurrences of "Unable to locate persister") but I am already eagerly loading.
Furthermore, I even changed my data provider configuration to:
.Mappings(Function(x) x.FluentMappings.AddFromAssemblyOf(Of Project)())
I stepped through the code and actually saw it find the Project mapping and step through it. There are no exceptions thrown while building the provider, but yet the web app still fails when I try to fetch a Project from the DB.
Update
I have tested this same exact code with a desktop application and it works perfectly fine. It seems to me the problem must be with NHibernate and the Web Application. Does anyone have any ideas about this specifically?
The answer to this, of course, is that I made a mistake.
I had two session factories in use in the same program and I passed a session from the wrong factory to one of my functions. So the error is correct, because the session it was passed was unaware of the Project type. I found this out eventually by looking at the Connection property of the session I was querying through.
Hopefully this helps someone else who may have made the same mistake.
I have a custom action which is used to elevate users to be able to log on as a service. This gets run during the installer. It works fine for years on every Windows operating system up until Windows Server 2012. When the below code is run on this version of Windows instead of getting a long back of 0 for success I get a different error code back.
LsaAddAccountRights(
IntPtr PolicyHandle,
IntPtr AccountSid,
LSA_UNICODE_STRING[] UserRights,
long CountOfRights)
The problem is the code appears to be different every time and is a very large number, e.g. 102938473.
I run the error code through the following method to get the error code but this returns a different large number which doesn't appear to be a valid error code.
LsaNtStatusToWinError(long status)
I have tried looking these error codes up, but with no luck. They seem to be randomly generated and nonsensical.
If I ignore the returned error code, It appears that the user is successfully allowed to log on as a service. So everything appears to be working, except I am getting an error code back. I could ignore this error code, but what happens when it is a valid error, I may ignore it in the future.
Extra Information
I can run the code that is in the Custom action fine on its own in a console application without error. Only when it is part of the wix installer it seems not to work.
I'd take a look at the WiX Util extensions's User element. The name attribute can be a property. Using the CreateUser, LogonAsService and UpdateIfExists attributes you can take an existing account and grant it the rights. Or perhaps you have more code that you can refactor.
Issue could be with the return type of LsaAddAccountRights in C#.
I was able to solve the issue by changing the return type of LsaAddAccountRights in C# from long to UInt32. Found this information here . This change must be done for LsaNtStatusToWinError and LsaClose as well.
All of a sudden the errors that Dojo (1.8.3 from Google CDN) is spitting out empty errors, which makes debugging impossibly hard. For example, if I forget to require a dependent before using it, I get the usual
> dojo/parser::parse() error ReferenceError {}
... in the error console, but I remember getting more information in the ReferenceError (spindown arrow was present), giving me the arguments of the error as well as the message making it easy to figure out what I had done wrong.
I have isDebug : true in my dojoConfig, but it just doesn't want to tell me anything anymore.
What gives?
I've been having the same problem using Dojo 1.8.3 as well. When I close my developer tool's console and then re-open it the Error had the spindown and more details as expected. Seems stupid, but give it a try and see if that at "fixes" it for you. I planned on digging a little further into this later, so if I find any additional details I will make sure to update my answer with them.