I am using microsoft ef-core and Sqlite database in my xamarin-forms app. My model is quite big, so I guess it's not a good idea to drop it here. I was working on the app for couple weeks and tested on my phone in Debug mode - everything worked perfectly.
But as soon as I've built RELEASE version - I got ArgumentNullException right on DbContext.EnsureCreated() call. I could find it using console output. So it says:
Value cannot be null. Parameter name: key
On DEBUG build my application works perfectly fine, and I have no build-dependent precompiler directives in my code also. Using Visual Studio 2017
Any thoughts or advices on what can I check?
UPD: here is stacktrace I got in Release:
I/mono-stdout(24851): TRACE: at System.Collections.Generic.Dictionary`2[TKey,TValue].TryInsert (TKey key, TValue value, System.Collections.Generic.InsertionBehavior behavior) [0x00008] in <d029cac6f9824b0bb72d5eb6d48d11f3>:0
I/mono-stdout(24851): at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (TKey key, TValue value) [0x00000] in <d029cac6f9824b0bb72d5eb6d48d11f3>:0
I/mono-stdout(24851): at Microsoft.EntityFrameworkCore.Sqlite.Query.Internal.SqliteDateTimeAddTranslator..ctor (Microsoft.EntityFrameworkCore.Query.ISqlExpressionFactory sqlExpressionFactory) [0x000c5] in <7b7aa88a95d54aa786bada86edd4821a>:0
I/mono-stdout(24851): at Microsoft.EntityFrameworkCore.Sqlite.Query.Internal.SqliteMethodCallTranslatorProvider..ctor (Microsoft.EntityFrameworkCore.Query.RelationalMethodCallTranslatorProviderDependencies dependencies) [0x0001d] in <7b7aa88a95d54aa786bada86edd4821a>:0
I/mono-stdout(24851): at (wrapper managed-to-native) System.Reflection.MonoCMethod.InternalInvoke(System.Reflection.MonoCMethod,object,object[],System.Exception&)
I/mono-stdout(24851): at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <d029cac6f9824b0bb72d5eb6d48d11f3>:0
The reason behind this is that the linker is being overly aggressive and it strips System.DateTime class from mscorlib assembly. The proper fix is, instead of preserveDateTimeMethods solution that you mentioned, to create a Custom Linker Configuration.
Create an empty file LinkDescription.xml
Add it to the OS-level project (Android, iOS, etc).
Set its build action to LinkDescription
Add System.DateTime to the linker block
Here's how:
<?xml version="1.0" encoding="UTF-8" ?>
<linker>
<assembly fullname="mscorlib">
<type fullname="System.DateTime" preserve="methods" />
</assembly>
</linker>
So, I've searched for hours and as soon as I've posted quiestion..
Looks like it's a ef-core bug - a linker problem working with DateTime types leading to attempt of adding null-key value to Dictionary.
Links to bug discussion:
https://github.com/dotnet/efcore/issues/14091
https://github.com/dotnet/efcore/issues/10963
I had this problem on my Android release build, so I've added line of code from one of comments on first discussion.
Added this line in my MainActivity.cs before Xamarin.Forms initialization:
var preserveDateTimeMethods = DateTime.Now.AddYears(1).AddMonths(1).AddDays(1).AddHours(1).AddMinutes(1).AddSeconds(1);
It resolved my problem. Hope it helps somebody.
Related
I'm kinda new to xamarin. I got this error when I'm switching from debug mode to release mode, I search everywhere but I got no answer.
Severity Code Description Project File Line Suppression State
Error Mono.Linker.MarkException: Error processing method: 'System.String Microsoft.Net.Http.Headers.DateTimeFormatter::ToRfc1123String(System.DateTimeOffset,System.Boolean)' in assembly: 'Microsoft.Net.Http.Headers.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve Microsoft.Extensions.Primitives.InplaceStringBuilder
at Mono.Linker.Steps.MarkStep.HandleUnresolvedType(TypeReference reference)
at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference)
at MonoDroid.Tuner.MonoDroidMarkStep.MarkType(TypeReference reference)
at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body)
at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method)
at Mono.Linker.Steps.MarkStep.ProcessQueue()
--- End of inner exception stack trace ---
at Mono.Linker.Steps.MarkStep.ProcessQueue()
at Mono.Linker.Steps.MarkStep.ProcessPrimaryQueue()
at Mono.Linker.Steps.MarkStep.Process()
at Mono.Linker.Steps.MarkStep.Process(LinkContext context)
at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context)
at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
at Mono.Linker.Pipeline.Process(LinkContext context)
at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context)
at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res)
at Xamarin.Android.Tasks.LinkAssemblies.RunTask()
at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/builder/azdo/_work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 17"
Trevor answer worked for me, but there is alternative solution.
I've noticed that this missing class Microsoft.Extensions.Primitives.DateTimeFormatter was removed from Microsoft.Extensions.Primitives dll in version 4.0. Some of dependencies to my project required version >=3.2 and some >=5.0. I guess linker chosen to link higher 5.0 version so the other dependency failed to find removed class.
Solution is to update all dependencies so their dependencies uses versions of Microsoft.Extensions.Primitives >=5.0
Turning linking off is the lazy answer. The point of using the linker is to remove "dead" code and minimize the size of the program. The size of a mobile app is more important to many users.
The linker used in Xamarin.Android is going to remove code it thinks you are not using. This is especially true when using reflection. To fix this you would need to tell the compiler you're using the type.
A popular solution is to use a LinkerPleaseInclude.cs file and make stub methods using the type and properties so the compiler thinks you're using them. You will find many examples on the Internet.
public class LinkerPleaseInclude
{
public void KeepInplaceStringBuilder(Microsoft.Extensions.Primitives.InplaceStringBuilder x)
{
x.Append('x'); // This will keep the InplaceStringBuilder.Append method from being linked out...
}
}
A newer solution is to use a Custom Linker Configuration XML file. This is a bit less of a "hack" than the LinkerPleaseInclude.cs solution, but more verbose. It allows you to preserve the whole type, specific methods, properties, etc.
<linker>
<assembly fullname="Microsoft.Net.Http.Headers">
<type fullname="Microsoft.Extensions.Primitives.InplaceStringBuilder">
</assembly>
</linker>
Either solution will work. Just keep doing this for each of the types the linker complains about and it will eventually work.
I keep getting the error like this:
Error System.IO.FileNotFoundException: /Users/Nathaniel/Library/Caches/Xamarin/mtbs/builds/EagleEyePrism.iOS/7b66664107c017167463bbde19c6a2f4/obj/iPhone/Debug/optimized/upload_blue.png does not exist
File name: '/Users/Nathaniel/Library/Caches/Xamarin/mtbs/builds/EagleEyePrism.iOS/7b66664107c017167463bbde19c6a2f4/obj/iPhone/Debug/optimized/upload_blue.png'
at System.IO.File.Copy (System.String sourceFileName, System.String destFileName, System.Boolean overwrite) [0x00193] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-08/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/File.cs:111
at Xamarin.MacDev.Tasks.SmartCopyTaskBase.CopyFile (System.String source, System.String target, System.String targetItemSpec) [0x0002d] in <cd319828b05749ae9de0c80034a6d2bc>:0
at Xamarin.MacDev.Tasks.SmartCopyTaskBase.Execute () [0x000b6] in <cd319828b05749ae9de0c80034a6d2bc>:0 EagleEyePrism.iOS
It doesn't matter what file it is. If I remove upload_blue.png, it throws an error on the next Resource.
I have tried everything. I have deleted the Xamarin cache on the Mac, I've deleted AppData\Local\Xamarin on the PC, it simply will not compile.
If I set all the BundleResources to Embedded Resources, it will compile and run, but then none of my image collateral gets displayed.
I've scoured the internet for hours trying to solve this problem.
I'm running the latest XCode on the Mac, with MacOS Mojave, and Windows 10 with Visual Studio 2019 on the PC.
I solved it by disabling the Optimize PNG images option in the iOS Build Options
Project:
ASP.NET 4.5.2
MVC 5
Visual Studio 2015 (latest)
When building the project, today it mysteriously began erroring out with the error in the title. Now, it is not the build which is failing, but the publish:
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========
Now, I have gone into the temp build folder, at
[path to project]\obj\Release\AspnetCompileMerge\Source
And it seems to have all the files needed to push to the sandbox, but when I do so attempting to reach the site errors out with a massive message (50+ lines). Will append once I have them formatted.
Suggestions?
NOTE: Other projects still compile just fine. This is limited to this project, specifically.
NOTE 2: I have seen several requests to use aspnet_compiler.exe with the -errorstack flag in the commandline, but I have yet to figure out what the -v and -p flags mean, so I am currently unable to provide the output. I have never used the commandline for development before, so details would be appreciated.
UPDATE 1: I actually figured out the command, and this is what I got:
D:\[path to project]>aspnet_compiler.exe -errorstack -v /[project] -p D:\[path to project]\
Microsoft (R) ASP.NET Compilation Tool version 4.0.30319.33440
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
D:\[path to project]\web.config(43): error ASPCONFIG: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
[ConfigurationErrorsException]: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS. (D:\[path to project]\web.config line 43)
at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
at System.Web.Configuration.RuntimeConfig.GetSectionObject(String sectionName)
at System.Web.Configuration.RuntimeConfig.GetSection(String sectionName, Type type, ResultsIndex index)
at System.Web.Configuration.RuntimeConfig.get_Compilation()
at MTConfigUtil.GetCompilationConfig(String vpath)
at System.Web.Compilation.BuildManager.IsBatchEnabledForDirectory(VirtualPath virtualDir)
at System.Web.Compilation.BuildManager.PrecompileWebDirectoriesRecursive(VirtualDirectory vdir, Boolean topLevel)
at System.Web.Compilation.BuildManager.PrecompileWebDirectoriesRecursive(VirtualDirectory vdir, Boolean topLevel)
at System.Web.Compilation.BuildManager.PrecompileWebDirectoriesRecursive(VirtualDirectory vdir, Boolean topLevel)
at System.Web.Compilation.BuildManager.PrecompileAppInternal(VirtualPath startingVirtualDir, IEnumerable`1 excludedVirtualPaths)
at System.Web.Compilation.BuildManager.PrecompileApp(VirtualPath startingVirtualDir, IEnumerable`1 excludedVirtualPaths)
at System.Web.Compilation.BuildManager.PrecompileApp(ClientBuildManagerCallback callback, IEnumerable`1 excludedVirtualPaths)
at System.Web.Compilation.BuildManagerHost.PrecompileApp(ClientBuildManagerCallback callback, List`1 excludedVirtualPaths)
at System.Web.Compilation.BuildManagerHost.PrecompileApp(ClientBuildManagerCallback callback, List`1 excludedVirtualPaths)
at System.Web.Compilation.ClientBuildManager.PrecompileApplication(ClientBuildManagerCallback callback, Boolean forceCleanBuild)
at System.Web.Compilation.ClientBuildManager.PrecompileApplication(ClientBuildManagerCallback callback)
at System.Web.Compilation.Precompiler.Main(String[] args)
In particular, note:
This error can be caused by a virtual directory not being configured as an application in IIS. (D:\[path to project]\web.config line 43)
Problem is, the only thing in my Web.Config at that line is
<authentication mode="None" />
You see, because the IIS built into VS 2015 crashes every time I stop debugging, I set up IIS on Windows itself and just pointed it toward my project directory. But it was working just fine up until now. Could this be the issue?
EDIT 2: Commenting out line 43 in my Web.Config now throws this:
This error can be caused by a virtual directory not being configured as an application in IIS. (D:\[path to project]\web.config line 46)
Clearly there is something very, very strange. Considering I have published at least twice since I last changed my Web.Config.
Ended up doing a backup of the project, nuking it from orbit, repaving with a new blank project, adding back in all the required NuGet packages and then copying over from the backup all the files I had directly edited. Including all the Migrations files also helped, as it meant I could pick up with the DB right where I left off. The only thing I had to walk through with a fine-toothed comb was the Web.Config -- I wanted to make sure this was set up perfectly, so I hand-edited it like a surgeon doing brain surgery.
FYI, I coped everything over through the file system while the project was unloaded, and then “included into the project” anything I had previously created from scratch.
Not the ideal situation, but hey. This project is still under construction, so I lost just about an hour or two at the most doing the rebuild. The tough part was dumping my Team Services repository, as it wouldn’t accept the new project. I did this after I confirmed the new setup was working 100%, as I wasn’t too concerned about not being able to roll back beyond a certain date.
After refactoring a solution I had a file containing a commented out class, so it only had the using clauses and namespace set. It was using a namespace that was no longer in use by any files but may have been cached somehow so didn't immediately error.
Building didn't pick it up and it caused the aspnet_compiler exited with code 1 error plus a few other unrelated errors that weren't errors. Removing the empty class file fixed it. Also remove any old namespaces from Views/web.config.
I found the following exception in my error log:
System.NullReferenceException: Object reference not set to an instance of an object.
at Glimpse.AspNet.RequestMetadata.get_ClientId()
at Glimpse.Core.Framework.GlimpseRequest..ctor(Guid requestId, IRequestMetadata
requestMetadata, IDictionary`2 tabData, IDictionary`2 displayData, TimeSpan duration)
at Glimpse.Core.Framework.GlimpseRuntime.EndRequest()
at Glimpse.AspNet.HttpModule.EndRequest(HttpContextBase httpContext)
at Glimpse.AspNet.HttpModule.<Init>b__3(Object context, EventArgs e)
at System.Web.HttpApplication.SyncEventExecutionStep.
System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I'm running glimpse core v1.6, the following config:
•Registered Tabs:
◦Other ◾Elmah - Glimpse.Elmah.Plugin
◦Glimpse.Ado (1.5.0)◾SQL - Glimpse.Ado.Tab.SQL
◦Glimpse.AspNet (1.4.0)◾Configuration - Glimpse.AspNet.Tab.Configuration
◾Environment - Glimpse.AspNet.Tab.Environment
◾Request - Glimpse.AspNet.Tab.Request
◾Routes - Glimpse.AspNet.Tab.Routes
◾Server - Glimpse.AspNet.Tab.Server
◾Session - Glimpse.AspNet.Tab.Session
◦Glimpse (1.6.0)◾Timeline - Glimpse.Core.Tab.Timeline
◾Trace - Glimpse.Core.Tab.Trace
Want to create your own Tabs - see here!
•Runtime Policies: ◦Glimpse (1.6.0)◾Glimpse.Core.Policy.AjaxPolicy
◾Glimpse.Core.Policy.ContentTypePolicy
◾Glimpse.Core.Policy.ControlCookiePolicy
◾Glimpse.Core.Policy.GlimpseResourcePolicy
◾Glimpse.Core.Policy.StatusCodePolicy
◾Glimpse.Core.Policy.UriPolicy
EDIT:
Some more info:
This is running on an Azure web site. While the uncaught exception gets logged (by Elmah), I don't think an error page every makes it's way to the end user.
I had a similar problem.
After various checks, the problem was resolved by resetting Visual Studio settings.
Tools > Import and Export Settings
I just came across this issue today. Turns out it simply that I needed to update the Glimpse NuGet packages as I was using versions that were no longer supported by the newer MVC / ASP.NET technology.
After this, I got a runtime error relating to the System.Web.Mvc.Html reference in my Web.Config. This was subsequently fixed by Cleaning my solution then changing the "Copy Local" property against the System.Web.Mvc reference to True.
If I run this command on my system
<Exec Command="C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -v localhost -p $(SourceDir)\wwwroot -u -f projectCompileCode\project -c -errorstack -nologo" />
I get the following error:
error ASPParse: Could not load the type: Projectname:SomeFile.
The project is web application project
This my stack trace:
[HttpException]: Could not load type 'ProjectName.FileName'.
at System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCa
e, Boolean throwOnError)
at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeN
me, String codeFileBaseTypeName, String src, Assembly assembly)
at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDicti
nary parseData)
[HttpParseException]: Could not load type ''ProjectName.FileName.
at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virt
alPath, Encoding fileEncoding)
at System.Web.UI.TemplateParser.ParseReader(StreamReader reader, VirtualP
th virtualPath)
at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPat
virtualPath)
at System.Web.UI.TemplateParser.ParseInternal()
at System.Web.UI.TemplateParser.Parse()
at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType(
at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(
uildProvider buildProvider)
at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders()
at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()
at System.Web.Compilation.ApplicationBuildProvider.GetGlobalAsaxBuildResu
t(Boolean isPrecompiledApp)
at System.Web.Compilation.BuildManager.CompileGlobalAsax()
at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()
at System.Web.Compilation.BuildManager.PrecompileAppInternal(VirtualPath
tartingVirtualDir)
at System.Web.Compilation.BuildManager.PrecompileApp(VirtualPath starting
irtualDir)
at System.Web.Compilation.BuildManager.PrecompileApp(ClientBuildManagerCa
lback callback)
at System.Web.Compilation.BuildManagerHost.PrecompileApp(ClientBuildManag
rCallback callback)
at System.Web.Compilation.BuildManagerHost.PrecompileApp(ClientBuildManag
rCallback callback)
at System.Web.Compilation.ClientBuildManager.PrecompileApplication(Client
uildManagerCallback callback, Boolean forceCleanBuild)
at System.Web.Compilation.ClientBuildManager.PrecompileApplication(Client
uildManagerCallback callback)
at System.Web.Compilation.Precompiler.Main(String[] args)
If I build in v2.0.50727 then still it is giving the same error.
My application is built in with VS 2010, .net frame asp.net frame work 4
Any help is greatly apperciated.
Have you tried:
Checking references
Doing a clean and a build
Checking the Inherits attr in the HTML against the code behind
Creating a new App Pool in IIS for this web site?
I see a similar problem. Works locally from within VS2008, but once published and deployed to the server, I get the same error as described here.
None of the suggestions I have provided worked for me; maybe they will work for you.
I had the same error. When I opened the web site DLL in ILDASM, the Type for a control was completely missing, as if it didn't even get compiled.
As it turns out, the codebehind files got excluded from the project. This is strange considering that the builds on my machine were successful! At any rate, I carefully re-included codebehind files and it all started working.
This often happens because the project file (.csproj or .vbproj) does not contain the necessary references to the files in question. Try cleaning/rebuilding all projects and making sure that the latest project files are moved to the server as well.
Another possibility is that the file was not actually included in your project at all. This allows the builds in Visual Studio to run just fine, but will break when compiling the .NET code (with aspnet_compiler for example) because all .aspx/.ascx/etc. files within the specified folder are compiled - whether they are included in your project or not.