I am new to UWP. I have just ported a quite complicated WPF app. It took me several weeks to figure out every difference and refactored a lot of code. However when I start to build and run in release mode I get an Access violation exception.
How is this even possible? Aren't debug and release execution supposed to be the same? How can I debug this problem if it occurs only in release?
If I turn native compilation off, the release build runs without a problem. However, when I try to install it on the device, a NetCore 2.2 debug framework is required. What is this debug framework and why cannot I run my release code without it?
I used to develop for AspNetCore and those things can run even on Linux. I really do not understand how is a UWP app cannot run on a Windows 10 tablet without a special debug framework.
I am kind of lost here. Any help or guidance is much appreciated. Thanks
EDIT:
As for the conclusion: I needed to create the app again from scratch. I started copying everything from the old app class by class. It was worth the effort not just because I refactored a lot of code :) but finally found what was causing the crash. I had a dependency in one of my libraries to an older version of System.ServiceModel.Primitives NuGet package. In Debug build, even with Native Compilation, the runtime managed to resolve the package. However, in Release it could not.
It was quite a journey that made me to develop a better software. However I could avoid it by releasing more often from the beginning, or the if the runtime would show more informative error messages about assembly resolution problems.
The .NET Native compilation tends to cause problems for apps and it is recommended to try and run the application frequently in the release mode to catch potential issues as soon as possible. Usually any reflection-related code should be checked well, as those usually are the source of problems.
I would suggest going back in time (if you have some kind of source control) and try earlier builds of your app to pinpoint the time when the app stopped working. Alternatively, you can try commenting out parts of the code until the release build starts working. Finally, it is also possible to create a blank project and sequentially copy code and run it to locate the problem.
.NET Native is an annoying aspect of UWP app development and Microsoft is aware of this - the plan is .NET Native will no longer be required anymore soon (most likely before .NET 5 comes) and later there will be a more predictable replacement.
Related
I have an issue on exported build release from Flash Builder 4.6. The case is when I run it on the IDE(Flash Builder 4.6) it works fine, no issues encountered, it never crashed but when I exported it for a release build and run, it crashes to a certain module/view. The view/module where the AIR app crashes has multiple remote object calls (minimum of 5). I have noticed that when requesting multiple remote object calls(like 5 remote calls at a time) it crashes. Is the remote object causes the crash? Please help me out on this guys, any idea will be much appreciated.
Thanks
Glen
I bet it's a security issue that you worked around when invoking the application from the ide. By default, Flash Builders working directories are marked as "secure", so you don't get any security issues. But when working on the live system, you might need to have a corssdomain policy.
Also: i suggest to use the Thunderbolt logger with the logging framework. This allows you to get log informations straight into your browser's console.
I'm developing a mobile AIR application using IntelliJ.
When debugging in Flash Builder there is an option to clear to application data on each (debug) launch of the ADL (see screenshot below) However, I can't find this setting in IntelliJ or some ADL parameter to force a clear on each new debug session. I was wondering if such an option exist in IntelliJ or ADL.
A little background: I'm using the PersistanceManager in the application to store some user settings and I want to be able to start the application without the saved settings from my previous run. Using this setting in Flash Builder does the trick, but I'm having no luck with IntelliJ.
Not sure, never had to do that before, but I believe that if you do a "clean" before rebuilding, that should clear out the PersistanceManager.
Yes im still trying to find a solution for this.
The reason this happens is because when you are testing on the device, for some reason IntelliJ sends an uninstall command to the device so it wipes clean everything.
I tried to run my own compiler arguments, but the uninstall command has higher priority so i can't cancel it yet. I think a good solution could be using ant tasks: http://livedocs.adobe.com/flex/3/html/help.html?content=anttasks_1.html
I use a third-party DLL (FTD2xx) to communicate with an external device. Using Qt4, in debug mode everything works fine, but the release crashes silently after successfully completing a called function. It seems to crash at return, but if I write something to the console (with qDebug) at the end of the function, sometimes it does not crash there, but a few, or few dozen lines later.
I suspect a not properly cleaned stack, what the debug build can survive, but the release chokes on it. Did someone encounter a similar problem? The DLL itself cannot be changed, as the source is not available.
It seems the reduction of the optimization level was the only way around. The DLL itself might have problems, as a program which does nothing but calls a single function from that DLL crashes the same way if optimization is turned on.
Fortunately, the size and speed lost by the change in optimization level is negligible.
Edit: for anyone with similar problems on Qt 5.0 or higher: If you change the optimization level (for example, to QMAKE_CXXFLAGS_RELEASE = -O0), it's usually not enough to just rebuild the application. A full "clean all" is required.
Be warned - the EPANET library is not thread safe, it contains a lot of global variables.
Are you calling two methods of that library from different threads?
Whats the advantage of pre-compiling an ASP.NET project using aspnet_compiler.exe?
Also, is there a possibility that a the compiled project will have errors after it is being deployed to a remote server? There is an issue raised by the team that maybe if the machine where the project is compiled and the server where the project will be deployed will have different settings, the project will not run or run erroneously. Has anybody encountered this situation?
I see two principle reasons:
Compile time error checking.
Avoiding overhead of compile on first page fit.
The first of these allows more errors to be detected while in development (e.g. typo in property name) rather than getting the yellow screen of death. If the code in question is an error path, it can be hard to ensure test coverage so things can slip through.
This cannot guarantee that there will be no errors in production. Clearly logic errors will not be found at compile time, nor will missing error handling (to name but two huge categories of bugs).
Also it will not prevent missing reference problems due to a missing assembly (present on the development machine but not deployed to production). Thus good practice is still to have a staging environment (this could also be for acceptance testing) which is treated by developers and testers as if it were production --- only access is to deploy a corrected version (no direct fixing) so fixes all start in development (and source control).
Another advantage is protecting your source code if you have to deploy to an untrusted environment (e.g. shared hosting), as you only deploy binaries which make it much harder for a third party to do any reverse-engineering than if you have all your .cs files up there.
You won't see any cross-platform issues just from performing the compilation. Check out this answer which explains how .NET runs on different architectures.
Has anyone ever bothered about the fact that BizTalk has a lot of annoying deployment/building problems.
For example if I use c# assembly classes to be build/deployed I regularly get sgen.exe errors, which get fixed if I remove them from my assembly, however then some dependencies are giving problems again, which then means I have to rebuild it and restart visual studio because they don't trigger the assemblies otherwise. And yes I always use the build event command:
"C:\Program Files\Microsoft Visual
Studio 8\SDK\v2.0\Bin\gacutil.exe" /i
$(TargetFileName)
I also experience a lot of problems wwith serializing String or Booleans etc while building, which also become fixed after I restart my visual studio solution.
Also when you want to import an .msi file you have to unenlist & remove all running instances to have it deployed decently.
And let's not forget about restarting your host instances, which is an option on your visual studio project but barely ever works so manually restarting your host instances has become more than a routine.
Let's face it, there's a lot of other things which also keep on rising like references problems etc, and I'm sure I can think of a couple more after a day of work.
Does anyone have some tricks regarding these issues? Because I encounter them hourly. I was just wondering if other people encountered these too and maybe solved a couple of these issues.
About restarting host instances, I have found the following "bts-reset" PowerShell script to be extremely useful:
http://winterdom.com/2006/09/btsresetwithpowershell
It doesn't solve the problem, but it's faster to use than restarting host instances from the BizTalk admin console.
Otherwise, I agree with you that deployment is really too complex (especially when you have multiple projects/applications with dependencies between them), but the only "solution" I have is to carefully break down your projects/applications in a way that will minimize the problem.
We installed SP1 for BizTalk yesterday. The performance has improved a lot! Starting our orchestrations used to take ages. Only takes a couple of seconds now!