I'm not very experienced in C#, done some small stuff with it, but it's quite similar to Java, only different, so no fuss. For my current project I need a small web server. So I've been looking around and found that a lot of people are doing a HttpListener based thing. Great, I can do that, but I also ran into the Kayak web server (https://github.com/kayak/kayak) and I figured using a little more seasoned framework may be a good idea.
So I started to try and add it to my project; searching for a DLL to add. But it seems I'm suppose to check out the source and compile it using Rake. Really? Is that how frameworks in C# are distributing; 'old' style Unix "please compile me"? Expecting something like Maven may be too much, but... Or is this an exception?
Some open source projects need you to compile them from scratch - others provide NuGet packages. Often a project won't have a pre-packaged build until they reach v1.0, for example.
In the case of Kayak, there is a NuGet package, so that's probably what you should use.
Note that NuGet is only "reasonably" new (last couple of years) so there will be old, stable projects which haven't required any changes recently which may not have packages, and you may well find many developers who are going to use the project who aren't familiar with NuGet.
You are definitely looking for: http://nuget.org/packages/kayak
NuGet can be used from command line or as a Visual Studio addon - both work very well.
Related
I am working on a Unity project (idk if that's relevant), but very often whenever I try to view a quick documentation popup in JetBrains Rider with CtrlQ the popup contains only the link to the online learn.microsoft.com page without providing any sensible inline help. This really hinders my workflow and forces me to make mental context switches.
Is this really the whole content of quick documentation that is available for those elements or is something broken on my side? Is their documentation reaaaaally that scarce? I thought that some basic doc for Enumerable.<LINQ queries> or Regex.* would be present...
(#EDIT even simple things like Console.WriteLine() are missing inline docs...)
Can I get the offline MSDN documentation that would be displayed in this popup?
Could it be a problem with my mono/dotnet installation, and if so how can I fix it?
IMPORTANT: I'm on Ubuntu 20.04 and using Rider 2021.3.2. I've also installed the documentation module for my unity editor instance, but I doubt it comes with MSDN included.
#UPDATE: It seems to be a unity/assembly problem, as plain C# projects do have inline documentation hints, only projects generated by unity are missing them. I tried reinstalling unity editor instance from the hub, but the documentation is still missing.
It turns out it is a Unity problem. I Managed to fix that (but it's hacky) using this unity forum thread as a reference and this bug report. I located the netstandard.xml files across my system (locate netstandard.xml command on Linux) and put it under /.../Unity/Editor/2021.2.8f1/Editor/Data/NetStandard/ref/2.1.0/netstandard.xml. (previously there was only a netstandard.dll with no xml file there).
Why isn't this shipped with the unity itself is beyond me. I had luck because I could easily find the location of my dotnet-sdk files on my machine.
If someone has other working and less hacky solution, I am happy to accept it.
#EDIT seems like unity broke something once again, because this solution no longer works... After going to symbol for any thing (e.g. ArrayList's Add()), the decompiled sources point to .../Unity/Editor/2022.1.22f1/Editor/Data/UnityReferenceAssemblies/unity-4.8-api/*.dll. I guess the "solution" would be to download and place the .xml for each corresponding .dll in this directory...
I don't really know what happened. Did I change the .NET API compatibility level somewhere? Did I change build platform (Mono, IL2CPP) or something? I don't know... (I started using the dynamic keyword which is a .NET 4.0 feature, which possibly upgraded my API Compatibility version to .Net Framework and I now target different dlls). But I shouldn't have to bother in the first place — documentation should be working by default, but we have to deal with unity here, so no surprise it's broken :)
#Edit I got frustrated by this lack of basic functionality and I "fixed" it myself... Here is a tool all of you can use to make this semi-automatic: https://t3st3ro.github.io/packages/unityIntelliSenseFixer/
It comes bundled with xmls that seem to work and a script that links them to automatic directories. Hit me up here or somewhere on my page if you have some improvements...
I tried to import a winform solution file from VS code (windows) to monodevelop (Linux) but it failed. The error is as follows:
Error while trying to load the project '/home/virtuall_kingg/Camera_GUI/Camera_GUI/Camera_GUI.csproj':
File not found: /home/virtuall_kingg/Camera_GUI/Camera_GUI/Camera_GUI.csproj
I added Camera_GUI.csprojfile also but still the error is same.
Can anybody guide me on how to import solution to mono?
This winform project has become pain in my neck.
Is building the GUI using gtk# in Ubuntu from scratch is the only way?
EDIT: Now you can substitute mono with .NET 5, the common .net framework for all platforms.
You are asking multiple questions here. In Linux you have (limited) support for WinForms through Mono. Depending on how complex is your project, you could port it without modification. If there are p/Invokes, then you won't for sure be able to port it.
Yep, in Linux the "other" big option is Gtk#, which has a long history. If you would want to port the project starting from scratch, it'd be a good option, but it'd involve porting your classes from working with WinForms to Gtk#, which is not impossible, but not trivial either. The feasibility of this would mainly depend on how good that project is architected. Do you have bussiness logic and views separated? If the answer is no, then the process will be tedious, and as hard as lengthy.
MonoDevelop is an IDE for C#, and Visual Studio for Mac is roughly MonoDevelop. It certainly works in Linux... as well as Visual Studio Code. So, there is no need to change anything in that front if you just need to port your code to Linux.
Okay, now, what's the road to follow? I think the best one is to try Mono with WinForms. It'd maybe involve simplify some code in the user interface part, but is certainly feasible. Just remember that you need to install Mono, and if your project is set to target .NET Core, then you need to create another project from scratch and set it to target .NET Framework.
Now, the specific question is that MonoDevelop complains about a missing Camera_GUI.csproj. This means that you've only picked a few files, but not the whole solution. Any IDE (Visual Studio, Visual Studio Code, Rider...), would complain about the same thing. Either remove the project from the solution, or add the project with all its files to the directory in which the solution sits.
So, the answer is: don't change anything if you don't need to retarget your project. Just move to a Linux box or virtual machine, with the whole project and open it in Visual Studio Code Rider, Rider, or MonoDevelop it does not matter. From within the IDE, remove those projects that make no sense in Linux (i.e., windows installer), and then recompile and start the program. Polish those parts of the user interface that need tweaking and that's it.
Should you need more help, please be more specific and provide more info.
On a Mac, using Mono 2.6, and wanting to get started with protobuf-csharp-port.
I just compiled protoc from protobuf-2.3.0 from google. Or should I use protobuf-2.4.0 which recently came out? Also for protobuf-csharp-port should I use the Download of 0.9.1 (May 2010) or go ahead and clone the Git master branch?
So, looks like successfully compiled the AddressBook tutorial using 2.3.0 + 0.9.1. Wanting to know if it's advisable to go with protoc 2.4.0 + git master?
Thanks in advance and looking forward to digging in to protobuf-csharp-port.
Alex
I can't say I've used protobuf-csharp-port on a Mac. It's probably best to go with the 2.3.0 build of protobuf as that's the version of protoc I use on Windows.
I would suggest using the latest version of protobuf-csharp-port on github; that includes a few new features in ProtoGen such as automatically calling protoc for you - although it assumes protoc.exe, so you'll need to tinker with it to call the Mac version. You can also specify various of the generation options from the command line instead of "polluting" an otherwise portable .proto file, which is nice. Unfortunately I don't have documentation for that yet, but feel free to ask for information on any specific bit :)
The github repository also has support for the "lite" runtime, if that's useful to you. That's a reasonably recent addition which hasn't had as much usage as the rest yet, just to warn you. I don't know of any problems, but just be aware of its recentness :)
I'm starting a new project in MonoDevelop, and I want to see how other projects are using it.
I tried searching through SourceForge, code.google.com, etc., but mostly I was just finding things like add ins or something related to MonoDevelop itself.
So is there anyone else using MonoDevelop, especially open source?
Basically, MonoDevelop is designed to function very similar to Visual Studio, including using all the same sln/proj file types. You can take a VS solution, open it in MD, and hit F5 to run it, and vice versa.
Because of this, I don't know that many people are going to write about "how they use MD as part of their project" any more than someone is going to write about how they use Notepad.
Any project that is using sln/proj files on Linux/Mac is likely using MD.
MonoDevelop is multiplatform IDE, especially for Linux. Works with Visual Studio solution and project files (100% both direction compatibility). So you can't find project using it. Any C#/VB.NET project can be developed in MD.
Three years ago me and a friend started work a new mono project and tried to use MonoDevelop for it. However - this was an impossible mission - we got ridden with all kinds of bugs and crashes and in the end I said - go to hell MonoDevelop - I'll use my tried and true Emacs.
To tell you the truth with no features other than formatting and font locking Emacs turned out to be 10 times more productive environment for me. My friend somehow endured using MonoDevelop for the whole run of the project, but afterwards he said he was done with Linux for good if it offered such low quality dev tools.
Times were different back then, I've been following mono's development and monodevelop's as well - they seem to be turning out quite well. I think that the actual cause of your problem - not finding anything - lies in the fact that most Linux devs openly shun Mono as a development platform because of it's Microsoft roots. This is sad - because it's a solid alternative of Java - especially at the desktop applications front(GTK# is seriously cool).
Banshee seems to be using MonoDevelop. Probably most of the prominent mono projects with a GUI use it as well to some extent.
I've found MonoDevelop to be excellent so far. I've only been using it for about a month, but once I got it set-up the way I want it, I wouldn't go back to any other editor or IDE on Linux. It took me a while to figure out how to set the debugger up and configure the editor to how I like it.
It's almost like having Visual C# Express on Linux.
Try searching for MonoTouch projects. Mac + MonoDevelop + .NET iPhone apps.
I just tried compiling my project, 2 problems:
couldn't load Setup projects
couldn't load SQL Server Library projects
There is a way around this of course, just have to consider that not all project types can be built in mono and must design solution the way it doesn't stop you from building what you want.
we have a number of c# projects that all depend on a common DLL (also c#). this DLL changes somewhat frequency as we're in an environment where we need to be able to build and deploy updated code frequently. the problem with this is, if one of these updates requires a change to the common DLL, we end up with several client apps that all have slightly different versions of the DLL.
we're trying to figure out how to improve this setup, so we can guarantee that anyone can check out a project (we use SVN) and be able to build it without issue. it seems like tagging each and every DLL change to a new version is excessive, but I'm not sure what the "right" solution is (or at least something elegant).
it would be ideal if any solution allowed a developer to be able to step into the DLL code from visual studio, which only seems to be possible if you have the project itself on your machine (might be wrong there).
Frankly, I think versioning your DLL in source control is the RIGHT solution.
It's very possible that a quickly changing core DLL could cause binary and source compatibility in a client project. By versioning, you can prevent each project from using the new DLL until you're ready to migrate.
This provides a level of safety - you know you won't break a client's project because somebody else changed something underneath you, but it's very easy to upgrade at any time to the new version.
Versioning in SVN is trivial - so I wouldn't let this be an issue. It's also safer from a business perspective, since you have a very clear "paper trail" of what version was used with a given deliverable of a client project, which has many benefits in terms of billing, tracking, testability, etc.
There's no easy solution - and the previous two answers are possibly the more accepted method of achieving what you want. If you had a CI environment, and were able to roll out all of your apps on-demand from a store that was built via CI, then you could avoid this problem. That can be lofty ambition, though, if there are old apps in there not governed by tests etc.
If your application is .Net 3.5 (might even need the SP1 too) then did you know that assemblies that are loaded from the network now no longer have any trust restrictions? This means that you could configure an assembly path on the machines in question to point to a shared, highly available, network location - and have all of your apps locate the assembly from there.
An alternative to this, but which would achieve the same goal, would be to build a component that hooks into the AppDomain.CurrentDomain.AssemblyResolve event - which is fired whenever the runtime can't auto-discover an assembly - and do a manual search in that network location for the dll in question (if you were to take the AssemblyName portion of the Full Name, append .dll to it, then you'd be reproducing the same search that the .Net Fusion binder performs anyway).
Just a thought ;)
I think you could benefit from setting up a continuous integration server with targets for each of the client projects and the common DLL project.
This way you'll immediately know when changes in the common DLL breaks any of the client projects. It could reduce the trouble of updating client projects when common DLL's interface changes. This solution might be inadequate if you development team is distributed and very large.
I wouldn't say there is a RIGHT solution though. There are many ways to manage dependency problems.
You could also have a look at Maven. It will help you set up project dependencies. Not sure how you can integrate Maven into Visual Studio though. Maven will allow you to specify which version of a project (in SVN) you want to depend on. Developers will then be able to checkout the correct project version and build their projects. Maven will checkout the correct version of the dependent projects from SVN for them. I haven't work with it myself, but a lot of open source projects in the Java community uses it.