Adding ReactiveUI to my WinForm project, it fails to compile due to the below error.
I have removed unnecessary packages as well checked their version to not differ from each other. Even it conflicts with "System.Reactive.Core". I have removed it from entire solution and also cleaned the solution but it is still referring to it.
I am sure someone using ReactiveUI might have faced this, I am not even getting any reference for this error so posting this question.c
2> System.InvalidOperationException: Duplicate type System.ObservableExtensions from System.Reactive.dll, was also present in System.Reactive.Core, Version=2.2.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
2> at ILRepacking.RepackImporter.Import(TypeDefinition type, Collection`1 col, Boolean internalize)
2> at ILRepacking.Steps.TypesRepackStep.RepackTypes()
2> at ILRepacking.Steps.TypesRepackStep.Perform()
2> at ILRepacking.ILRepack.Repack()
2> at ILRepacking.Application.Main(String[] args)
Related
I have a Menu Form and it has 7 UserControls every time I execute my program I keep seeing this error.
I have no idea what error is this. I tried searching but there are no error close related to mine. Then I compare my error with this Project Assemblies error
Can anyone help me with this? I have no idea what causes this error.
The error is caused by your code looking for the MS Access database file called:
MonitoringSystemDatabase.mdb
...is located at path:
C:\Users\crims\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies\cjz5kapb01\
...but it is not.
Locate file MonitoringSystemDatabase.mdb (perhaps with +E to Search), note the actual path of the file, and correct the path in MainMenu.vb.
The error message is very clear, so why all the searching?
Either the file isn't there, or the application can't see it where it expects to find it.
Try moving the file to:
C:\Users\Public\Documents\MonitoringSystemDatabase.mdb
and adjust you project accordingly.
I am seeing this message in the error logs for failed windows phone 8 log.
[01/19/16 12:18:58.565] ERROR: Oh no, XMLVM needs more memory. Try running with -Xmx1G or more.
Think you could up the -Xmx setting there for me? If that's not the problem, then there is also this higher up in the log:
[01/19/16 12:04:20.276] ERROR: Couldn't create node for com.codename1.impl.ImplementationFactory
[01/19/16 12:04:20.276] ERROR: Couldn't create node for com.codename1.impl.ImplementationFactory
And this lower down (but i think it's a symptom of XMLVM quitting without completing):
Main.cs(10,28): error CS0234: The type or namespace name 'Object' does not exist in the namespace 'java.lang' (are you missing an assembly reference?) [C:\Users\Shai\AppData\Local\Temp\build3939039400849280052xxx\App\App\App.csproj]
Main.cs(10,45): error CS0234: The type or namespace name 'Runnable' does not exist in the namespace 'java.lang' (are you missing an assembly reference?) [C:\Users\Shai\AppData\Local\Temp\build3939039400849280052xxx\App\App\App.csproj]
Looking thru the Codename One discussion group I found this: https://groups.google.com/d/msg/codenameone-discussions/gyjS81rpR3w/nSVxzWOJdXEJ
So I guess just adding the build hint win.doubleRam=true should solve that issue.
From Hadley's C best practices:
Like with C++, whenever you use C code in your package, you should unload the DLL when the package is unloaded:
.onUnload <- function (libpath) {
library.dynam.unload("mypackage", libpath)
}
Writing R Extensions on the other hand doesn't even mention this. I can see how it would be polite to unload the dlls, but doing so seems to cause some weird problems for me with packages that are loaded/unloaded/reloaded (see example further down). Additionally, there are some mentions that suggest maybe unloading isn't required. From ?library.dynam:
Note that whether or not it is possible to unload a DLL and then reload a revised version of the same file is OS-dependent: see the ‘Value’ section of the help for dyn.unload.
though this shouldn't affect objects that are not modified. Then there is this comment from Brian Ripley in R-devel:
Having said all that, my experience is that unloading the DLL often does not help if you need to load it again (and that is why e.g. tcltk does not unload its DLL).
So is it acceptable to leave the C libraries loaded? I would prefer not to have to dig into why stuff like the below is happening (did not happen before I started unloading libraries).
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin13.1.0 (64-bit)
> library(alike) # install_github("brodieg/alike", ref="fdaa578e"), if you're curious
> library(data.table)
data.table 1.9.2 For help type: help("data.table")
> detach("package:data.table", unload=T)
> detach("package:alike", unload=T)
> library(alike)
> library(data.table)
Error : .onLoad failed in loadNamespace() for 'data.table', details:
call: address(x)
error: object 'Caddress' not found
In addition: Warning messages:
1: In FUN(X[[9L]], ...) :
failed to assign RegisteredNativeSymbol for alike to alike since alike is already defined in the ‘data.table’ namespace
2: In FUN(X[[9L]], ...) :
failed to assign RegisteredNativeSymbol for typeof to typeof since typeof is already defined in the ‘data.table’ namespace
3: In FUN(X[[9L]], ...) :
failed to assign RegisteredNativeSymbol for type_alike to type_alike since type_alike is already defined in the ‘data.table’ namespace
Error: package or namespace load failed for ‘data.table’
The warnings are all related to alike functions. alike did not use to unload its dynamic libraries, and the above errors did not happen. After I implemented unloading the errors started happening. Note that data.table 1.9.2 did not unload its DLLs, though other packages that also don't unload DLLs didn't cause this problems. data.table 1.9.4 works fine.
Normally unloading a DLL would be a good idea. The resources it owns, would be completely freed, and re-loading would not be an issue.
In R, there is the complication of the R environment, because even if a DLL is unloaded, there may be some knowledge left behind in the R runtime. In this case, the result may be that the re-loaded DLL library does not share the same inferred state as the R variables which are intended to understand the DLL state, and thus errors occur.
I think it would be possible for an R package (DLL and R code) to be safely unloaded, but it would be easier for you to leave the DLLs loaded, unless you find particularly heavy resource usage.
From XAML, I am attempting to set the icon from the Window control.
The .ico file is located in a different assembly (no subfolders). I can get this to work when I just add the file to this assembly, but my goal is to make this work with having only the original .ico file, and having it stay where it is.
I have tried:
Icon="pack://application:,,,/ReferencedAssembly;component/IconFile.ico" as well as Icon="/ReferencedAssembly;component/IconFile.ico"
Even without the nasty blue squiggles, when I try to run I get errors of:
'Provide value on 'System.Windows.Baml2006.TypeConverterMarkupExtension' threw an exception.' with an InnerException of "Could not load file or assembly..... The System cannot find the file specified."
Win7, .NET 4
This seems like it should be simple enough, yet I am stumped. Thanks ahead of time.
Thanks to srsyogesh for helping get some additional error info.
I noticed it was failing to download the assembly initially, and that was a silly error on my part from failing to notice that that reference was completely missing.
With that fixed, it was followed by a "ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.", with an inner exception of "An attempt was made to load a program with an incorrect format". That was apparently caused by a conflict of "x86" vs "Any CPU" Platform Target in the build settings. Changed the one that said "Any CPU" to "x86", and voila.
I followed the tutorial on http://silversprite.codeplex.com/ and got rid of a few issues that were expected (the colors etc). But there is 1 compile error left:
Error 2 The type 'Microsoft.Xna.Framework.Graphics.VertexDeclaration' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\Microsoft.Xna.Framework.Graphics.dll' and 'C:\Users\Brandon\Desktop\SilverSprite.dll' C:\Users\Brandon\Desktop\Projects\Other projects\Game Jam prac\Silverlight3dApp1\Silverlight3dApp1\Silverlight3dApp\VertexPositionColorNormal.cs 31
I've been searching for over an hour and can't find a solution.
The error means exactly what it says: There is a type, VertexDeclaration, that is being defined by both Silverlight and by SilverSprite. When your project tries to resolve which one to use - it can't decide.
SilverSprite is, and has always been, kind of buggy. This appears to be a bug in SilverSprite. It's coming from this file, which contains a declaration of VertexDeclaration which is nothing like the actual API.
Fortunately you don't have to implement it yourself - because Silverlight provides it. I suggest you download the SilverSprite source and include it as a project in your solution, and reference that instead of the DLL (ie: build SilverSprite from source yourself). Then you can easily modify it and simply delete the bogus type definition - your code will then automatically use the real one.
If you come across any other bugs, I suggest you look at ExEn. I made it last time I tried to use SilverSprite (although this was before Silverlight 5) - and I fixed many, many bugs. You might find it useful to salvage code from.