When I try to install IronPython on Debian with Mono (3.12), I get the following error:
socket.cs(1900,63): error CS0117: `System.Net.Sockets.SocketOptionName' does not contain a definition for `IPv6Only'
How can I solve this problem? According to the IronPython website, everything should compile without errors.
In the Mono mailing list there is already such a bug, but there is no answer to this bug. Therefore I thought that maybe this forum is a better place for this question.
I'm no expert on either IronPython or Mono, but out of curiosity I just tried this.
For whatever reason, the IPV6Only value in the SocketOptionName enum appears to be missing in the Mono implementation. The error message you're getting is from the code in IronPython.Module/Socket.cs attempting to reference this. It turns out that this is already recognised in the codebase as a feature that not all platforms have, so there's an easy workaround:
The Common.proj project file in the Solutions/ directory in your git checkout defines a number of possible ReferencedPlatform values. The default value is V4. Just below there in the XML, find a block starting:
<PropertyGroup Condition="'$(ReferencedPlatform)' == 'V4'">
Nested in there is a Features element with a list of the features that apply, and if you find and delete FEATURE_IPV6 at the end of the list, then you should find that the project will build using make. I briefly tried firing up the ipy.exe that is generated and it seems to work.
Obviously this isn't a very good solution. Probably the best thing would be to file a bug report with the IronPython project. I guess that Mono on Linux is probably a fairly low priority for the guys who are working to maintain it.
Correct, up to mono 4.0 throws Protocol option not supported when setting IPv6Only false.
This is probably resolved here: https://github.com/mono/mono/blob/mono-4.2.0-branch/mono/metadata/socket-io.c#L536
But do note the compile flag IPV6_V6ONLY
Related
I can't get monodevelop to work on Manjaro. I tried all the different options to install in AUR (monodevelop-beta, monodevelop-bin, monodevelop-git, monodevelop-nuget3, monodevelop-stable) and most of them failed to build.
The only one that didn't fail was monodevlop-bin, but I couldn't get it to build my program. At first I got this error:
The imported project "/usr/lib/mono/msbuild/15.0/bin/Roslyn/Microsoft.CSharp.Core.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. (MSB4019)
There was no folder "Roslyn" in the specified location. I made a folder with that name and copied the file Microsoft.CSharp.targets from msbuild/15.0/bin/ in the "Roslyn" folder (renamed the copy to Microsoft.CSharp.Core.targets).
It probably wasn't a good idea, but I tried it, just in case.
That did seemed to work, but then I got another error:
Parameter "AssemblyFiles" has invalid value "/usr/lib/mono/4.7-api/mscordlib.dll".
Could not load file or assebly 'System.Reflection.Metadata, Version=1.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a or' or one of its dependencies. (MSB3248)
doctorzeus commented on 2019-12-14 14:34
Since the issues with compatibility with the latest version of mono and msbuild as well as
there no longer being a "stable" build mode on the github project I am disowning this project.
Sadly I stopped using this IDE in favor of VSCode a while ago and also no longer have the time to maintain it with the large number of incompatibilities with the various dependencies.
Hopefully someone with more time will take over..
This is from the original maintainter/builder (at the time of writing) in the comments of the AUR page. After him, it seems that another person tried to continue maintaining it, but he still failed:
coder2000 commented on 2020-03-31 18:51
The build process is currently broken and the documentation is incomplete.
So, for now, you can't use monodevelop on Arch based systems (at least from AUR). You will have to use alternative IDEs, like JetBrains Rider, or text editors (with proper extensions), like VSCode or Atom.
Also, from personal experience, I would advice against using Arch based distributions for programming, because of problems like that. Use Ubuntu or something Ubuntu based for easiest experience with programming tools (I use Linux Mint for programming and I haven't had any major problems).
I tried searching but haven't found an answer. I upgraded SonarQube from 5.6 to 6.3 by taking the steps outlined here: https://docs.sonarqube.org/display/SONAR/Upgrading
SonarQube was upgraded and up and running quick enough, but then some problems occured. New results weren't being imported for alot of projects and even if they are, things aren't looking good.
The broken importing seems to be related to character set differences. I get crashes like: java.lang.IllegalStateException: Unable to read the source file : 'D:/Builds1/SF/CA AanvraagData/Sources/AAHG.AanvraagData.Client/AAHG.AanvraagData.Client.snk' with the charset : 'UTF-8'.
However, I only have the latest C# plugin installed as language plugin. Why is SonarQube even trying to read .snk files? I never had this problem before, and from what I understand SonarQube should only import known filetypes (sonar.import_unknown_files is set to it's default of false). I can manually exclude alot of extensions, but I'd rather not.
The few projects that actually get imported seem to have issues which presenting C# code in testclasses (no syntax coloring). Also the sonarqube runner gives alot of errors like this: Unable to TFS annotate the following file which is not in a mapped TFS workspace. A little further on in the output the annotating does seem to work for the same file all of a sudden. Also, I'm getting debug lines saying stuff like this: 'ontwikkel.config' indexed with language 'null'. Again.. why is it trying to index files other than .cs? Havent looked at these issues since they're minor in comparison which entire projects not importing, but if anyone has a suggestion that would be great.
Things I tried:
- Updating the scanner to the latest version (2.2), but that isnt helping. Reverted back to 2.0
- Manually excluding files - seems to be working to some extend, but I do not want to rely on this. I'm working with 60 other developers..
- Checking upgrade notes to see if I missed anything
- Checking jira for known issues, but I don't really know what to look for
Can anyone help me out here? Thanks!
With regards,
Whistler
There seems to be a bug in SonarQube 6.3 which results in the behavior I'm describing, resulting in projects failing to import when using in/exclusions: http://jira.sonarsource.com/browse/SONAR-8995
I'm writing a C# Gtk# application under Mono/MonoDevelop in Linux Mint 17. I have a ComboBox on a form with 3 items in it. I was able to place it and such fine however, I get an error in the designer code stating that the ComboBox doesn't contain a definition for 'NewText'. The Mono documentation at docs.go-mono.com says that this NewText method is how you add items, however, apparently mine doesn't have it.
My MonoDevelop version is 4.0.12
The projects target Gtk# version is 3.0
I have the following references and their versions referenced in the project
And finally, the designer code
//top of file declaration
private global::Gtk.ComboBox framestyle_Val;
//further down, this defines all the items
this.framestyle_Val = global::Gtk.ComboBox.NewText ();
this.framestyle_Val.AppendText (global::Mono.Unix.Catalog.GetString ("Single Sprite"));
this.framestyle_Val.AppendText (global::Mono.Unix.Catalog.GetString ("Left/Right Sprites"));
this.framestyle_Val.AppendText (global::Mono.Unix.Catalog.GetString ("Left/Right/Upside-Down Sprites"));
It's worth noting that apparently there's no AppendText definition/method either but I assume that'll be straightened out once we get this one straightened out.
Any ideas? I'm confused myself. Thanks in advanced,
Mike
I had the same problem. MonoDevelop seems to be unable to generate proper code to use with Gtk#3.
You may want to install Gtk#2, this will not override the GTK#3 installation, and target your project with this version to be able to use MonoDevelop's visual design abilities.
And maybe you will need to create the clean GTK#2 project once again.
If you have found a solution to use GTK3, please give me an idea.
I spent a sleepless night trying to build QUICKFIX to have the 64-bit version of quickfix_net.dll and quickfix_net_messages.dll
My C# Framework is 64-bit and the regular offered QUICKFIX dll's are 32-bit, so I have no other choice (Switching back my app to 32-bit is NOT an option)
I was expecting the VS_10 solution to build instantly (Poor little naive bunny...) but I have a bunch of unfound libraries errors (cannot open source file "xxxxxx.h") for many #include "xxxxxx.h" statements. I have this behavior for the two project sources I have tried. I am puzzled as I am more of a .net guy and I did not manage to fix this on my own.
The original project source is downloadable here and the 64-bit fork which interest me most is here
If some of you could open quickfix_vs10.sln and have a clean compile I would be MORE than grateful as I could then get at least a couple of hours sleep in the company's basement before getting back to work.
EDIT :
Detailed Errors :
I have many unrecognized #include "quickfix/foo" > I have to remove all the "quickfix/" prefixes from the entires solution
'FIX' : is not a class or namespace name (especially in FieldMap.h)
missing type specifier - int assumed. Note: C++ does not support default-int
-'QuickFix::FieldNotFound __gc &' : unable to throw or catch a managed object by value or reference
I have hundreds of each and many more... :(
EDIT : EFFICIENT ANSWER
If you want a REAL .Net FIX Engine, then you'd better go for VERSAFIX or QUICKFIX/N
Both are native .Net and Open Source, and hence compilable as x64 dlls (or x86if you like)
QUICKFIX/N just came out and is very promising. Too bad it came out a few months after the post :(
As of VERSAFIX, my company has used it for 6 Months and we are pretty satisfied so far.
(Russ Curry, the project initiator is technically rock solid and responsive.)
You should check out QuickFIX/n, a FIX library built specifically for .NET (without the unmanaged C++ wrapper). QuickFIX/n keeps all the good conventions of QuickFIX.
I needed the 64 bit version of quickfix aswell few days ago and here is how i did it and had no errors or problems at all converting it to 64bit. Unrar a new instance of the archive open it with VS.
Then go to properties of the entire solution and select Configuration Properties. Then press "Configuration Manager" button and from the drop down of "Active Solution Patforms" chose "New". Now select x64 from the first drop down and from the second "Copy settings from:" select "Mixed Platforms". After you do this just rebuild the solution and you are done.
I hope this help you all guys. Have a nice day.
The header (.h) errors are due to it being unable to find the include folder. If you add that folder to the list of places that the project looks for header files it should build fine. I had this problem as well but, bing a c++ dev knew what it was instantaneously, I admit it would have taken me a while if I weren't so au fait with c++ and it's quirks
I have a C# application which links to a few c# DLLs which in turn use bindings to call c++ functions in other Dlls.
This all works fine if I compile the c++ Dlls with /MTd but when I use /MDd I get an XMLParseException in my C# app complaining that it can't find any Dlls(it fails to find the first of my Dlls that I use). My best guess is that using this other switch causes it to change the path where it looks for its Dlls, causing it to fail. I used DependencyWalker to have a closer look and the two Dlls it actually fails to find are 'IESHIMS.DLL' and 'WER.DLL'. I can't see my c# Dlls anywhere in the tree in DependecyWalker however. Anyone have any ideas what might be wrong here?
Also, using the non-debug equivalents (/MD and /MT) make no difference. Regardless, I can't use /MT as it causes another bug.
EDIT: I've narrowed the problem down somewhat. When compiled and linked using the VS2010 command prompt, my app works fine, with the VS2008 command prompt it still fails to find the Dll. Does anyone know any differences between these two version of VS which could cause the behaviour I described above?
Thanks in advance,
Are you compiling all the modules against the same run-time libraries? From:
http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
"All modules passed to a given invocation of the linker must have been compiled with the same run-time library compiler option (/MD, /MT, /LD)."