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);
Related
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?
I've kicked my head with this one for several days now. I've done a lot of research and have found issues closely related but not specific to my case.
Working on a Visual Studio 2008 SSIS package. Using only one scripting component. In this scripting component, I am serializing a stongly typed class (CCMSModel) and trying to write it out to the server's d:\ drive. I am using .NET 3.5. Works just fine on my development machine but breaks when I deploy it to my SQL Server 2008 R2 (SSIS). I've completely trimmed down my code to remove any added complexity:
[Serializable]
public class CCMSModel
{
public string BOBorEOB { get; set; }
}
...
List<CCMSModel> myList = new List<CCMSModel>();
CCMSModel item = new CCMSModel();
item.BOBorEOB = "Test";
myList.Add(item);
string filePath = "d:\\ScheduleFiles\\6xml\\ss.xml";
var serializer = new XmlSerializer(typeof(List<CCMSModel>));
using (var stream = File.OpenWrite(filePath))
{
serializer.Serialize(stream, myList);
}
...
Want to add that I have sufficient rights to write on the server and I am a sysadmin on the sql server. I also have an another SSIS package using Visual Studio 2012 (SSIS) with .NET 4.0 and deploying to SQL Server 2012. This package is EXACTLY the same (did a copy / paste of the code) and it works just fine.
In my research I found an article that I couldn't help but to see a very close relationship to. Same error and same code. However, this particular scenario is using .NET 4.0 and is deploying or executing in an environment that has .NET 4.0 and 4.5. The article contains a link (at the bottom) claiming to solve the problem (specific to the 4.0/4.5 framework). Claims that the XMLSerialize, in 4.5, is a bit different from the one that runs on my C# compiler hence the incompatibility.
InvalidProgramException with XmlSerializer
Although the article present a close resemblance, this isn't specifically my set up (since I am on 3.5). However, it does allude to the fact that I may be experiencing some incompatiblity with the XMLSerialise implementation. I've hunted down to see if this was the case but I've run dry on my search.
I get an this inner exception error:
System.TypeInitializationException: The type initializer for 'Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterList1' threw an exception. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterList1..cctor()
I have a big problem which makes me cry everytime when I try to resolve it.
I have installed VisualStudio2012 Express and made project in .net 4.5 framework it is simple project which use QUARTZ library and has only 2 lines:
var cron = new Quartz.CronExpression("0 * 8-22 * * ?");
DateTimeOffset? nextFire = cron.GetNextValidTimeAfter(DateTime.Now);
I successfully have compiled application and it works fine. But one day I had to change framework from .net4.5 to .net 4.0 and when i did it VisualStudio throws errors in line
DateTimeOffset? nextFire = cron.GetNextValidTimeAfter(DateTime.Now);
Exception is:
"An unhandled exception of type 'System.AccessViolationException' occurred in WindowsFormsApplication6.exe
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
I tried to change framework from net4.0 to .net4.5 because in .net4,5 application worked fine but it does not works! I can go back to .NET4.5 but application throws the same System.AccessViolationException.
Have Anyone know how to resolve this issue?
I was facing this same problem.Somehow my project configuration for build was set x86.
It was not giving me option to change it.I unloaded project and changed it in notepad.Build configuration was set as "AnyCPU" and things started working problem
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!