Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Lately I've been working on a few little .NET applications that share some common code. The code has some interfaces introduced to abstract away I/O calls for unit testing.
I wanted the applications to be standalone EXEs with no external dependencies. This seems like the perfect use case for static libraries. Come to think of it third party control vendors could benefit from this model too.
Are there some hidden nasties with static libraries that I've missed?
Is there any reason why the C# designers left them out?
Edit: I'm aware of ILMerge but it doesn't offer the same convenience as static libraries.
.NET does in fact support the moral equivalent of a static
library. It's called a netmodule (file extension is usually
.netmodule). Read more about it in this blog post.
Beware that it isn't well supported by the Visual Studio
build tool chain. I think extension methods are a
problem as well. ILMerge is the better tool to get this
done.
This is not directly related to C#, but to the whole .NET umbrella. Sure, it's possible to merge assemblies using ILMerge, but alas it's still a research project, but at least its license permits use for commercial endeavors. Other than that, the runtime (CLR) cannot be coalesced into a single executable, the target platform still needs .NET to be installed.
Edit:
I was typing this before you edited your post with ILMerge. I might be wrong but there is not additional benefits from avoiding the .NET-style dynamic linking at runtime. There's nothing wrong with putting the satellite assemblies together with the executable. Microsoft doesn't recommend putting them in the GAC.
Using static libs has the drawback that it is not patchable by the runtime provider (MS).
For example if you use static MFC libs and a securify issue or other bug is found in the MFC static libs, MS can not patch it (the code is already in your executable). Using shared Dlls allows for an easy patch at OS level without you caring about that.
Of course having shared libs has a small drawback: a dependency is taken and they must be installed on the system.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Say I have an application that is connected to a database, with its own forms that present data and allow data to be changed & entered, how would one extend the program to be extensible by a third party?
For example a third party would be able to write scripts that the user can run that would prompt the user for input. Part of the script would then take what the user inputed (integer/string/boolean) and do some basic programmatic things to it, math on integer values, concatenation on string values (and other string functions), and logical tests to trigger further user prompts etc etc, the scripting environment would also support reading/writing to the application's database.
Would this be done simply by having text files the program could run, with each line corresponding to a certain command? Then the application would read each line, figure out what command the line represents, and equate that to C# code? Are there any already existing solutions to this problem?
The question is fairly open, here some proven great extension tools:
Compiled Plugins written in C# would use Managed Extensibility Framework (MEF), a great and well designed extensibility option.
Scripted Extensions in C# might be possible soon when Roselyn is ready.
Scripting could also be accomplished by integrating Jurassic into your application.
There are several good choices if you want to embed a scripting language into a c# app. IronPython, IronScheme and IronRuby alL support the Dynamic Language Runtime so they can access objects from the host code. There's also Boo, which is a strongly typed CLR language that looks a lot like Python but can be easily embedded in a C# application and, like to the others, can interact with the host application. In general the embedding process is pretty simple - Michael Foord's IronPython site has a good example.
There's also NLua which is supposed to be a CLR friendly lua wrapper, but I have no personal knowledge of that one.
Out of all of the above, I'd expect the main thing driving your choice will be the preferences of the user base. Especially for the lightweight application you've described all of these choices should be well suited. If you wanted users to be able to do extensive programming on their own it's more complex, since the CLR ports of these languages dont usually support the same binary extensions as their C-based counterparts - for example, IronPython can't use the regular Perforce API module because it is built on a C-based binary extension module. All Iron* languages can use the same base class library as C#, though - you can import System.Windows.Forms into any of them to create GUI and so on.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Basically, the question is: Where (and in which format) should I store textual developer documentation associated with my Visual Studio projects?
To elaborate: XML comments are great, but they don't cover all use cases. Sometimes, you'd like to describe the class architecture of the project at a high level, add usage notes to your library or just leave any other kind of message to future generations of developers working on this project.
I'd like to add these documents directly as files into the Visual Studio project, to ensure (a) that they are available to the developer without further searching and (b) they are version controlled (using the same svn/git/whatever repository as the source code).
Currently, I add a folder _Documentation to the project and use text files, but I'm not sure if this is the best solution. Visual Studio does not have an option for automatically word-wrapping text1, and manually fixing line breaks after each change is annoying. On the other hand, Word documents don't work well with version control, and TeX is too much of a hassle to set up and teach on each developer PC.
Is there a well-established best practice for this?
1 I know that there's Edit/Advanced/Word-Wrap, but this only affects the display, not the file itself.
I just had the same issue - only I noticed that I was able to add a HTML-file. Once opened, simply switch to "Design" at the bottom of the screen.
You may want to change Build Action from 'Content' to 'None'
As it is a hard-coded HTML document, it is also possible to use inline pictures (e.g. a diagram)
Also for my purpose (programming guide, architecture description. database use examples) I opted to create a separate project (_Documentation) as a Windows Forms, as this will allow me (or a new programmer) to have a running example.
I use GhostDoc (visual studio add-on) for documentation of my project as I add classes, methods, properties etc: http://visualstudiogallery.msdn.microsoft.com/46A20578-F0D5-4B1E-B55D-F001A6345748
You have the option, in XML comments, to include a lot of data that you can then pick up with a tool like Sandcastle (site) and turn into an actual MSDN-style reference site.
I tend to use this method and just write long XML comments (MSDN comment tags) (where appropriate) using the <para></para> to generate paragraphs and explain any patterns, business reasons or architectural information necessary to future modifiers/developers. I also use it to give usage examples.
A good batch of tests (well written and named) can also really illuminate the purpose of code, acting as a spec.
I hope that might be a little informative in your research :)
XML Comments is best for documenting the particular method and not ideal for writing long conceptual content. Long XML comments could adversely affect code readability.
I liked Conceptual topic documentation feature of Sandcastle, we can create and store Conceptual documentation whether functional or architecture related and merge it with Code documentation (XML Comments). Markups which you can use in writing the conceptual topics are extendable which means we can even adhere to Enterprise templates.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am curious as to how people port open source projects such as Lucene and Hibernate from Java to .NET? Is it a simple matter of using the Java Language Conversion Assistant 2.0 released by Microsoft?
Unfortunately, there's usually a much greater effort involved for projects that large. What's efficient in one language may not be in another, and more importantly what exists in one language may not in another. NHibernate for example took years to port over, and they're still doing it (albeit adding features the whole time, like Linq).
It's usually a matter siting down and porting classes one by one, optimizing where possible, changing structures where needed. Things like generics, aliases and boxing all change in the port. Then, after you get it all over, there's often lots of optimization still left to be done (of course this is optional...), maybe it's events, maybe it's statics and extension methods, could be anything your new language/platform offers that the old one didn't.
Think of it this way, why are you porting it to .Net? I'd wager to say you're in one of two situations, one you're stuck using .Net because of work (doh, sorry!) or you like .Net because it offers you some advantage. In the second category that means you chose it over Java, so in porting you'd want to take advantage of whatever features that made you choose .Net in the first place.
Like Nick said it is not that simple. A lot more than just porting code is involved, especially if the architecture of the application you want to port isn't that great. You want to use the features of the language you are porting to, and sometimes they are design decisions that you might change, because they don't seem right to you. I am not going to reiterate what Nick said, but would like to add the following.
I would recommend following the development of Noda Time, which is Jon Skeet's attempt to port Joda Time from Java to .Net. Jon is actually documenting the experience on the following blog:
http://noda-time.blogspot.com/
I would recommend following the blog, the google groups page for this project, and google code project. The google groups and code page links can be found on one of the posts on the blog.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I've seen there are a few of them. opencvdotnet, SharperCV, EmguCV, One on Code Project.
Does anyone have any experience with any of these? I played around with the one on Code Project for a bit, but as soon as I tried to do anything complicated I got some nasty uncatchable exceptions (i.e. Msgbox exceptions). Cross platform (supports Mono) would be best.
I started out with opencvdotnet but it's not really actively developed any more. Further, support for the feature I needed (facedetection) was patchy. I'm using EmguCV now: It wraps a much greater part of the API and the guy behind it is very responsive to suggestions and requests. The code is a joy to look at and is known to work on Mono.
I've wrote up a quick getting-started guide on my blog.
We use OpenCVSharp the google code website is in Japanese but it uses the latest OpenCV builds and impliments IDisposable throughout. It seems to provide more functioanlity than any of the others we have seen to date and is still active. It has quite extensive example programs as well.
NuGetMustHaves has a good summary of packages on NuGet with their build dates and OpenCV revs.
As of 1/24/2023:
EmguCV is updated for OpenCVv 4.6.0.5131
OpenCvSharp is updated for OpenCV v4.7.0.20230115
EmguCV and OpenCvSharp are the 2 packages with recent builds and appear to be the better choices going forward.
Beware, EmguCV uses a dual GPL3/Commercial license (source) whereas OpenCVSharp uses the BSD 3-Clause License. In other words, OpenCVSharp is free for commercial use but EmguCV is not. EmguCV has superior documentation/examples/support and a bigger development team behind it, though, making the license worthwhile in many cases.
It's worth considering what your future use cases are. If you're just looking to get running quickly using a managed language, the wrappers are fine. I started off that way. But as I got into more serious applications, I've found building a python/C++ application has better performance and more potential for reuse of code across platforms.
I think it's important to note that the original question was asked in 2008, and OpenCV 2.0 was released in 2009. The version 2.0 release introduced a C++ wrapper which is significantly easier to work with than the older C interface that the OP was confronted with. For my .NET project, I'm leaving all the graphic manipulation in native C++.
Try this: create a C++/CLR DLL project which links to the OpenCV libraries. The OpenCV manual describes how to do this for a Windows C++ EXE, the same steps also work for a C++/CLR DLL. Then of course the DLL exports methods which are callable from a .NET EXE.
To test it, you should be able to incorporate any of the OpenCV samples into your DLL with a little tweaking. (Add the .CPP file to your project, convert the main() function to a class member, etc. - you know the drill...) A good test candidate might be the "mat_mask_operations" sample.
I think best wrapper is opencvsharp
http://code.google.com/p/opencvsharp/
I created a NuGet Package to make easy to start with OpenCv in C#, using EmguCV.
Check it out!
In Visual Studio search and add the myEmguCV.Net NuGet package.
https://www.nuget.org/packages/myEmguCV.Net
SharperCV was our tool of choice, and it doesn't let us down, for our robotics project. Even though it is currently marked as abandoned, the code is in really good shape, requires only minor tweaking to customize it for your need. No msgboxes, and actually very sane exception handling.
Not cross-platform, though, due to the interoperability layer.
I know this question has been answered for a long time, but I would like to add that there is a very good wrapper here. This is the new version of the openCV wrapper that you tried on code project. I've tried it for a couple of days and everything works perfect. Also, I got it working in minutes.
I don't know for the compatibility with mono but under Visual Studio 2010, it works like a charm and saved me ton's of time and money (my project is commercial and most of the library are open source with licence that doesn't allow commercial utilisation unless publishing the code)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
The community reviewed whether to reopen this question 7 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I maintain an old PC-only application written in Delphi 7. Although Delphi has served me very well in the past I now only use it for this one application and find my skills with the language diminishing. Its syntax is too different from my 'day job' languages of Java/Ruby so it takes me longer to get into the groove of writing new code, plus it is so old I have not used many interfaces so the code is not managed which seems ancient to me now!
Many of my users are moving to Vista which may run the app in compatibility mode or may have GPF problems depending on how their PC is configured by their IT department, so I have to do some maintenance on the application. I'm wondering if I should jump to a more familiar stack.
Is there an automated tool that will do the legwork of converting the code base to C#, leaving me to concentrate on the conversion on any non-standard components? I'm using an embedded database component called AbsoluteDatabase which is BDE compatible and using standard SQL throughout, and a native Delphi HTML browser component which can be swapped out with something from the Microsoft world.
How good are these conversion tools?
I am not aware of any automated tools for making that conversion. Personally I would suggest you stick with Delphi, maybe just upgrade to a new version. I have seen a couple code DOM's that attempt to convert from Delphi to C#, but that doesn't address the library issue.
CodeGear (formally Borland) has a tool for going from C# to Delphi that works OK. I would assume the tools that go the other direction will work the same (requiring a lot of editing). Here is a Swedish tool that works on the same CodeDOM principle to go from Delphi to C# (and a number of other languages). There are others, I just can't find them right now.
Another option would be to upgrade to a more resent version of Delphi for .NET and port your code to .NET that way. Once you get it working in Delphi for .NET (which will be pretty easy, except for the embedded DB, unless they have a .NET version) you can use .NET Reflector and File Disassembler reverse the IL to C#. You will still be using the VCL, but you can use C# instead of Object pascal.
Another similar solution would be to port it to Oxygene by RemObjects. I believe they have a Delphi Win32 migration path to WinForms. Then use .NET Reflector and File Disassembler reverse the IL to C#.
In short, no easy answers. Language migration is easier then library migration. A lot of it depends on what 3rd party components you used (beyond AbsoluteDatabase) and if you made any Windows API calls directly in your application.
Another completely different option would be too look for an off shore team to maintain the application. They can probably do so cheaply. You could find someone domestically, but it would cost you more no doubt (although with the sagging dollar and poor job market you never know . . . )
Good luck!
There has been a scientific report of a successfull transformation of a 1.5 million line Delphi Project to C# by John Brant. He wrote a Delphi parser, a C# generator and lots of transformation rules on the AST. Gradually extending the set of rules, doing a daily build, lots of unit tests, and some rewriting of difficult Delphi parts allowed him with a team of 4, among which some of the original developers, with deep Delphi & C# knowledge, to migrate the software in 18 months. John Brant being the original developer of the refactoring browser and the SmaCC compiler construction kit, you are unlikely to be able to go that fast
Many of my users are moving to Vista
which may run the app in compatibility
mode or may have GPF problems
depending on how their PC is
configured by their IT department, so
I have to do some maintenance on the
application. I'm wondering if I should
jump to a more familiar stack.
Unless you are doing something non standard, D7 applications should run fine in Vista.
As for conversion to C#, I would think that most conversion tools would be a waste of time. A better approach may be to rewrite the application from scratch.
There is no easy answer, but bear in mind that the Delphi.net variant of the language targets the .net runtime, and that different languages on .net can interoperate closely.
You could try getting it to compile in Delphi.Net, factoring into different assemblies and then converting the assemblies by hand one by one. Reflector could help be reverse-engineering compiled code into a skeleton of C# code - equivalent but without comments, internal variable names etc.
On the other hand, Delphi.net may be good enough (TM) for this project.
But unless you have a good test suite (I'm guessing probably not, given the state of the art in Delphi 7) you're going to introduce bugs.