I just came across an exception while trying something with Manatee.Trello. I was trying to create a Func like this:
var criteria = new List<string>
{
"(put a board ID here)"
};
var query = new Func<IEnumerable<Manatee.Trello.Member>, IEnumerable<Manatee.Trello.Board>>(
members =>
{
foreach (var member in members)
{
var selectedBoards = member.Boards.Where(b => criteria.Contains(b.Id, StringComparer.Ordinal));
boards.AddRange(selectedBoards); // Exception thrown here
}
return boards;
});
But the line marked above throws this exception:
System.TypeLoadException
{"Method 'get_StatusCode' in type 'Manatee.Trello.RestSharp.RestSharpResponse' from assembly 'Manatee.Trello.RestSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=783b036be1eaf5a7' does not have an implementation.":"Manatee.Trello.RestSharp.RestSharpResponse"}
I'm not sure if this is something I'm doing wrong with my code, or some kind of setup error I made in setting up my project with Manatee.Trello, perhaps the NuGet packages are jacked up...
Any tips on where to start looking would be much appreciated.
This situation was remedied by changing from the RestSharp provider included in Manatee.Trello to the provider in Manatee.Trello.WebApi. As I discovered in the library's documentation:
Manatee.Trello.RestSharp is backed by (you guessed it) RestSharp.
There have been some issues with the .Net 4.5+ versions, so it's
suggested you don't use this one unless you are using .Net 4.0 or
earlier.
Indeed, I am using .Net 4.5.2.
Related
Happens in the save below:
context.Update(myBigObject);
await context.SaveChangesAsync(); -> Hangs here and RAM goes up until all the memory is finished
It only happens when a db error occurs ("String or binary data would be truncated" to be exact, meaning trying to stuff too large string in a field that's too small).
It happens when nlog config is:
${exception:format=#}
One "fix" is to change it to:
${exception:format=toString} -> But then I lose all the inner exception logging
See nlog docs on the difference between :format=# and :format=toString:
https://github.com/NLog/NLog/wiki/Exception-Layout-Renderer
It's happening to more people than me (see bottom comment) and happening in both Serilog and Nlog (so maby it's a EF Core thing):
https://github.com/dotnet/efcore/issues/24663#issuecomment-1349965403
Any idea how to fix without using :format=toString in nlog config?
NLog 4.7 allows you to override the reflection for a specific exception-type (Ex. Microsoft.EntityFrameworkCore.DbUpdateException) like this:
LogManager.Setup().SetupSerialization(s =>
s.RegisterObjectTransformation<Microsoft.EntityFrameworkCore.DbUpdateException>(ex => new {
Type = ex.GetType().ToString(),
Message = ex.Message,
StackTrace = ex.StackTrace,
Source = ex.Source,
InnerException = ex.InnerException,
})
);
See also: https://github.com/NLog/NLog/wiki/How-to-use-structured-logging#customize-object-reflection
When trying to use the QueryCache library to do some L2 caching of a few entities, I am receiving a compiler error on .FromCache() indicating the QueryDeferred library is required. Documentation indicates QueryCache can be used as stand-alone.
using Z.EntityFramework.Plus;
namespace LookupValuesMap.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
LookupValueContext ctx = new LookupValueContext();
var companies = ctx.Companies.FromCache().ToList(); <-- error
Here is the error:
Error CS0012 The type 'QueryDeferred<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'Z.EntityFramework.Plus.QueryDeferred.EF6, Version=1.6.8.0, Culture=neutral, PublicKeyToken=59b66d028979105b'.
Thank you in advance!
J Kent
Disclaimer: I'm the owner of the project Entity Framework Plus
Due to how the library has been built, some "standalone" features like this one may have the Z.EntityFramework.Plus.QueryDeferred.EF6 requirement.
You can download the version from: NuGet
We will eventually fix it for no longer having to have this dependence.
I'm using StructureMap to load Plugins at the start of my application. At application startup, when I create the container I do a simple scan like:
internal static IContainer Init()
{
var container = new Container(a =>
{
a.Scan(scan =>
{
scan.TheCallingAssembly();
scan.WithDefaultConventions();
scan.AssembliesFromPath($"{AppDomain.CurrentDomain.BaseDirectory}Plugins");
});
});
ConfigureDebugSubstitutions(container);
return container;
}
But I see these errors in the console:
StructureMap could not load assembly from file <filepath>
I end up getting around it currently by manually loading the files into the AppDomain like this:
private static void LoadPluginAssemblies()
{
var pluginAssemblies = Directory.GetFiles($"{AppDomain.CurrentDomain.BaseDirectory}plugins", "*.dll");
pluginAssemblies.Each(a =>
{
Assembly.LoadFile(a);
});
}
But I'm curious why I'm getting this message from structuremap to begin with. I looked at the code, and it looks like any errors are simply getting handled. Any thoughts? I'm using version 4.0.1.318 and I didn't notice this until I upgraded StructureMap from version 3.1.4.143. Also, I'm using .Net v4.6.1 if it matters.
Looks like it might have been a bug.
So, yes, I know why. It's trying to load the assembly by name directly from the AppDomain, which is really more efficient and less error prone than loading by the file path. Fine and good, but it should be trying to fallback to loading by the file in your case. I'm addressing this right now and it'll be in 4.1.
https://github.com/structuremap/structuremap/issues/451
I am specifically getting the following error:
"The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid."
[TestMethod()]
public void salesOrderFillListTest()
{
SalesOrderController_Accessor target = new SalesOrderController_Accessor();
string orderNumber = "1954120";
SalesOrderData result;
result = target.FillingOrder(orderNumber);
Assert.AreEqual(null, result.ErrorMessage);
Assert.AreEqual(32, result.LineItems.Count);
Assert.AreEqual("WRA-24-NFL-CLEV", result.LineItems[7].ItemNumber);
Assert.AreEqual(2, result.LineItems[7].OrderQuantity);
Assert.AreEqual(1, result.LineItems[7].FillingFilledQty);
Assert.AreEqual(1, result.LineItems[7].FillingRemainQty);
}
The error is coming up on the line:
result = target.FillingOrder(orderNumber);
I'm a junior developer and haven't had much experience with the many possible causes for this error. My App.config page contains the appropriate connection strings. Any ideas where to look for this one?
Thanks!
I was able to successfully run tests found in another test project in the same solution. After looking more carefully I found that there were a few differences between the two connection strings in each project. The data in the failing test project had become antiquated. I updated the connection string and error resolved.
Thanks.
I have entities that I am getting via Entity Framework. I'm using Code-First so they're POCOs. When I try to XML Serialize them using XmlSerializer, I get the following error:
The type
System.Data.Entity.DynamicProxies.Song_C59F4614EED1B7373D79AAB4E7263036C9CF6543274A9D62A9D8494FB01F2127
was not expected. Use the XmlInclude
or SoapInclude attribute to specify
types that are not known statically.
Anybody got any ideas on how to get around this (short of creating a whole new object)?
Just saying POCO doesn't really help (especially in this case since it looks like you're using proxies). Proxies come in handy in a lot of cases but make things like serialization more difficult since the actual object being serialized is not really your object but an instance of a proxy.
This blog post should give you your answer.
http://blogs.msdn.com/b/adonet/archive/2010/01/05/poco-proxies-part-2-serializing-poco-proxies.aspx
Sorry, I know I'm coming at this a bit late (a couple YEARS late), but if you don't need the proxy objects for lazy loading, you can do this:
Configuration.ProxyCreationEnabled = false;
in your Context. Worked like a charm for me. Shiv Kumar actually gives better insight into why, but this at least will get you back to work (again, assuming you don't need the proxies).
Another way that works independent of the database configuration is by doing a deep clone of your object(s).
I use Automapper (https://www.nuget.org/packages/AutoMapper/) for this in my code-first EF project. Here is some sample code that exports a list of an EF objects called 'IonPair':
public bool ExportIonPairs(List<IonPair> ionPairList, string filePath)
{
Mapper.CreateMap<IonPair, IonPair>(); //creates the mapping
var clonedList = Mapper.Map<List<IonPair>>(ionPairList); // deep-clones the list. EF's 'DynamicProxies' are automatically ignored.
var ionPairCollection = new IonPairCollection { IonPairs = clonedList };
var serializer = new XmlSerializer(typeof(IonPairCollection));
try
{
using (var writer = new StreamWriter(filePath))
{
serializer.Serialize(writer, ionPairCollection);
}
}
catch (Exception exception)
{
string message = string.Format(
"Trying to export to the file '{0}' but there was an error. Details: {1}",
filePath, exception.Message);
throw new IOException(message, exception);
}
return true;
}