I am working on a WinForms application using EF 6.3 and .NET Framework 4.5.1. The application is compiled as X86 and running on different Win10 x64 machines.
The application throws a XmlException intermittently. After including the source code of EF, I pinned it down to:
System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderResource:
private bool TryCreateResourceStream(out Stream resourceStream)
{
resourceStream = _assembly.GetManifestResourceStream(_resourceName);
return resourceStream != null;
}
For some weird reason the embedded resource of the csdl gets corrupted.
For example the tag Name will be replaced by Naméy followed by some not printable characters.
Once you restart the application works like expected. Sometimes uses can work a whole day without problems and some times even a restart does not help and the have to do it a third time.
In the environment environment I can reproduce the problem but might have to start a debug session 20 times.
I cannot figure out which process my corrupt the stream returned by GetManifestResourceStream.
Any ideas?
Related
I have a C# WPF application. It uses a small commercial framework (https://www.inosoft.com/en/product/product-features/).
I'm building this application both locally and via a buildserver (Azure pipelines). I use a marketplace task to change the assemblyinfo.cs before building: https://marketplace.visualstudio.com/items?itemName=bleddynrichards.Assembly-Info-Task
The build server executes the following tasks:
NuGet restore
Inject/Edit assemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion with the right version info
Build
Now when I run this application, it starts up and runs for a while.
Quickly after starting I hook the VS debugger into the process.
Then all of the sudden the application crashes:
This is weird, because when I build locally, this runtime error does not occur.
Note that i set all properties to the same values for testing:
AssemblyVersion: 1.2.3.4
AssemblyFileVersion: 5.6.7.8
AssemblyInformationalVersion: 9.10.11.12
I then use Telerik justAssembly to compare the build output from my local build and the buildserver:
As we can see the local output (on the left) does not have a version added to the Application.LoadComponent(..) whilst the build server output (on the right) does.
public void InitializeComponent()
{
if (!this._contentLoaded)
{
this._contentLoaded = true;
Application.LoadComponent(this, new Uri("/HmiMetis;component/views/app.xaml", UriKind.Relative));
}
}
This means that this is the root cause of the runtime exception.
I find it weird that the build process on my local machine differs from the build server output. Both (should) use visual studio 2017 to build. Why does the buildserver add the version to the uri of loadComponent and my local machine does not?
Anyways, I need this exception gone.
Therefore I think the easiest way would be to force the buildserver to not add the version information under any circumstances. Is this possible and how?
Edit:
I Found a relating issue report that may have something to do with this:
https://github.com/dotnet/core/issues/3189
I have a problem that an instance of an AggregateException causes a TargetInvocationException after a couple of accesses to an Icon resource.
I broke down the problem to the following steps to reproduce (.Net 4.0 full or client profile):
Create a new WinForms application (a console application will not work)
Add an arbitrary icon (.ico file) to the resources
Add the following code to the constructor:
new AggregateException();
for (var i = 0; ; ++i)
{
var icon = Resources.Certificate;
}
You have to change the resource name to the name of your resource.
That's all. Yes I know that this sample doesn't make sense. It's just to illustrate the problem. My working code is much more complex and all of this code is needed.
Without creating this excection the application will work forewer. But if this exception is created the access to the resource will fail with a TargetInvocationException. The InnerException told me that the operation has been finished successfully(?!?!) having a two-line stack trace in System.Drawing.Icon (ctor + Initialize).
What can I do to prevent this problem?
EDIT
It seems to be a problem using Windows 7. A binary which fails on Win 7 will run correctly in Win 8.1.
I found the reason for that problem:
The following system configuration is needed to reproduce the issue:
Windows 7 German Edition
Microsoft .Net Framework 4.5.2 installed (yes I know my binary is compiled against .Net 4.0)
KB2901983 installed
Having a machine which only contains the .Net Framework without KB2901983 the program works fine. After installing KB2901983 the program fails for the same binary (no recompilation required).
I tried to uninstall KB2901983 but it doesn't help. If it was once installed the program will fail. I tested it on a clean Windows 7 German Edition.
We have an environment that has been successfully running a postgresql web application with
Entity Framework running on .net 4.0.
Somehow, on my machine only, a single Linq query fails where on others it is successful. The following is the linq query, context of which doesn't particularly matter. Point is, it works on other machines and not mine. Additionally, my machine can successfully do inserts and the like but not this one specific execution.
((SEntities)Context).c_app.MergeOption = MergeOption.AppendOnly;
app = (((from rec in ((SEntities) Context).c_application
where rec.app_id == CStatus.app_id
select rec) as ObjectQuery<c_application>)
.Include("c_status")
.Include("c_tasks")
.Include("c_product")
.Include("c_acct")
).SingleOrDefault();
On co-workers machines, a fresh checkout running in the same server configuration yields a succsful result.
However, on mine, the following is the exception I get:
System.Exception {System.Data.EntityCommandExecutionException}
InnerException:
{"ERROR: 42601: syntax error at or near \"LEFT\""} System.Exception {Npgsql.NpgsqlException}
If I look at the errorSQL entry in the debug window that comes up, a huge SQL is created with "select .... limit 2 left join..." which is invalid and where the error is occurring.
The question is, why is this only happening on my machine, and my compiled code deployed to the others and/or the same code executed on co-workers working? We have recently upgraded to a 64 bit app pool but the DLLs are deployed with it and from the output, are the correct ones.
Obviously I'm missing something on my machine but it's not in our source so its either an iis config or something in the gac that has caused problems.
Edit:
Despite checking, I had installed 4.5 when I did a developer preview install of Visual Studio. Since 4.5 is an in-place upgrade from 4.0, I was missing everything where it said "target 4.0" despite being 4.5. Apparently Microsoft fixed a bunch of bugs in 4.5 for Entity Framework (or made more) and this was one of them. Other people have had similar issues so not sure if it was a bug in 4.0 or a bug introduced in 4.5.
The following fixed the above for anyone who somehow may have
string sql = "SELECT VALUE a FROM c_application AS a WHERE a.app_id = #appId";
ObjectParameter[] queryParams = { new ObjectParameter("appId", CStatus.app_id) };
ObjectQuery<c_application> query = Context.CreateQuery<c_application>(sql, queryParams).Include("c_status").Include("c_tasks").Include("c_product").Include("c_acct");
CApplicationDao cApplicationDao = new CApplicationDao();
SetupDao<c_application>(cApplicationDao);
query.MergeOption = MergeOption.AppendOnly;
app = credApplicationDao.FindSingle(query);
My app runs fine on my machine (of course/famous last words). However, when deploying it to another machine on the network, it won't even start up. I ran my EventLog utility on that machine and it told me this:
Type:Error
Source: .NET Runtime
Time Generated: 06/12/2012 15:35:12
Message: Application: duckbilledPlatypus.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitialization
Exception
Stack:
at duckbilledPlatypus.PlatypusMainForm..ctor()
at duckbilledPlatypus.Program.Main()
So it's something in my main form's constructor that's the problem, apparently...which, I admit, is a little "busy":
InitializeComponent();
foreach (string arg in Environment.GetCommandLineArgs())
{
if (arg == "-DEBUG")
{
InDebugMode = true;
break;
}
}
SuspendLayout();
tsch = new ToolStripControlHost(dateTimePickerScheduleDate);
toolStripPlatypusMain.Items.Add(tsch);
CreateTableLayoutPanelAndChildren();
LimitPlatypusIDTextBoxesToOneChar();
ShareEventsAmongDynamicTextBoxes();
SetAllPlatypusDataControlsReadOnly();
ResumeLayout();
Does any of this look problematic? (it's all pretty standard stuff, except for the ToolStripControlHost).
Now as to the framework version: does the Event Log report the framework version used to create my app, or the framework version installed on the machine trying to run the app? If the former, and the latter does not have that framework installed, that's a problem, right?
So if that's potentially the problem, how do I determine which version of the .NET runtime is installed on that machine?
UPDATE
I don't know why this is, but I was able to see an err msg after running the app on the remote/deployment only when I right-click and select Run As (and ran as myself, as I don't have any "more special" privileges on that machine). When I did so, I got "Unable to find a version of the runtime to run this application."
If I simply 2-click the app, it dies without a whimper (no err msg).
View the
view the %WINDIR%\Microsoft.NET\Framework directory
to determine which versions of .NET are installed.
http://msdn.microsoft.com/en-us/library/y549e41e.aspx
Try running the Fusion Log Viewer on the problematic machine. It will provide details about binding failures.
http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.100).aspx
Make sure you run it as administrator. It silently fails if you do not.
UPDATE
Based on your error "Unable to find a version of the runtime to run this application.", I would suggest you don't have the same version of .NET installed on the box that your application targets. Did you verify the installed versions using the steps above?
Also see
.Net framework - "unable to find a version of the runtime to run this application"
I have a program that works fine on VS2008 and Vista, but I'm trying it on Windows 7 and VS2010 / .NET Framework 4.0 and it's not working. Ultimately the problem is that System.Diagnostics.PerformanceCounterCategory.GetCategories() (and other PerformanceCounterCategory methods) is not working. I'm getting a System.InvalidOperationException with the message "Cannot load Counter Name data because an invalid index '' was read from the registry."
I can reproduce this with the very simple program shown below:
class Program
{
static void Main(string[] args)
{
foreach (var pc in System.Diagnostics.PerformanceCounterCategory.GetCategories())
{
Console.WriteLine(pc.CategoryName);
}
}
}
I did make sure I'm running the program as an admin. It doesn't matter if I run it with VS/Debugger attached or not. I don't have another machine with Windows 7 or VS2010 to test it on, so I'm not sure which is complicating things here (or both?). It is Windows 7 x64 and I've tried forcing the app to run in both x32 and x64 but get the same results.
It seems performance counters were corrupted on my system. Although I didn't follow this post exactly, it led me to the solution. Here is what I did:
In an command prompt with administrator/elevate privileges typed the following:
lodctr /?
Useful stuff in there...
Then typed:
lodctr /R
According to the docs from the prior step, this gets windows to rebuild the perf registry strings and info from scratch based on the current registry settings and backup INI files. I have a feeling this is what did the magic. However, next I noticed the .NET performance counters were not there anymore so based on this I typed the following to reload them:
lodctr "C:\Windows\Microsoft.NET\Framework64\v4.0.20506\corperfmonsymbols.ini"
Note that this path is for .NET Framework 4.0 on x64. You can imagine the path for other variations of the framework/platform. I'm guessing you should always load the counters from the highest version of the .NET framework that you have installed, but that is just a guess.
I hope this helps someone else someday!