I have a challenge similar to creating-my-own-plug-ins-for-my-own-project-in-c# and late-loading-a-net-plugin-dll, with the added headache of being able to specify a version to use. My current idea is to simply use console apps, with folders named by version. I'd then find the folder and load the console app by known name, using Process.
I'd like to avoid having to write out and read in text, which is the only real way I can see for a console app to talk to my 'control' windows forms app. Using dlls seems like a possibility, but I haven't done much with dynamic loading before and it seems rather messy either way.
I've had a quick look at the Managed Extensibility Framework, but it's still under development, and aiming for .Net 4.0, which I might be able to look at, although I need this solution relatively quickly.
Any other ideas out there for accessing a specific version?
In the end I just used a well-known folder structure to contain different versions of console apps.
No, it's not clean, and probably not the best way to do it. However, I don't have control over the console apps/dlls, and this works without being too much to explain to the researchers I work with. They know research, C# is just a tool.
Related
I am looking for best practices for a portable C# project that runs on multiple platform. In my case I have different wrapper dll's for each platforms providing interface/classes, etc. Whereas thy are the same on each platform I still need to reference the corresponding dll on each platform. What are best practices in such a case?
I could use conditional references in the C# project file (with the technique described here). Then I would require to know if I am on Linux, Windows or OS X. How would I do that?
Another option is to create a separate project for each platform. But then I have code redundancy because I have to implement each interface/inheritance for each platform. While the implementation is identical they derive from de facto different types coming from different assemblies (though they are the very same when using them).
What are possible strategies in this case and what are the advantages or downsides?
I have done something like that some time ago. I do not know if one should consider my way as best practice, but it worked for me:
I did opt for the "separate project for each platform" approach (only MS-.net and MonoDroid for me at the moment), but worked around code duplication by simply putting both .csproj files into the same folder. I then added the code files used in the first project to the second one.
I tiptoed around any inconsisencies in the dependencies of my code by inserting conditionals, which I subsequently added to the according csproj.
The only notable downside of this approch is, that one gets frequent complaints from Visual Studio if reopening a file (by double-clicking in project explorer) in the second project, that is already opend via the first one (implying both are added to the same solution, as I did). But these notifications seemed to do no harm and I was able to happily code away.
Imho this slight annoyance is preferable to the trouble it would cause to have the same code in two places. Maybe this could be mitigated by keeping the code together in a proper source control system like Git (e.g. on two different branches), but as the multi-csproj approach worked so well for me, I did not try anything down that route.
I am working on a project where I will allow users to write some code, which will be compiled, loaded and ran, this code will allow the users to control certain parts of the application. However, with this just allowing them to insert C# into the running app, there are certain restrictions I'd preferably like to have in place.
Are there any ways that you can run a piece of code but lets say block out any System.Threading use or any System.IO use?
I know going through the code and removing any references would be possible, but I am sure there would be ways around that. Before writing this, I'd at least like to check there isn't an easier, more effective way.
I have googled but either I am looking in the wrong place or asking the wrong question. I do know, however, that you Stack Overflow people are geniuses. Any ideas?
Thanks, and any answer would be appreciated greatly!
Code Access Security might be what you are looking for.
Instead of going through the code and removing all the individual references, why not just limit the project references? Also, you might be able to leverage .NET permissions on a system by using the .NET framework configuration snap in to manage access to GAC, domain apps, etc. based on various options. (start > run > mscorcfg.msc to launch it) I don't know what the newer 4.0 option is to replace that configuration utility however. EDIT: To take it one step further you could, for example run the entered code with a service user account and limit that user's code access via this utility.
I am creating libraries that I will use across Compact Framework, Silverlight, WP7 and the full .NET runtime. I am aware that the question around sharing between Compact Framework and full .NET, or between Silverlight and full .NET has been asked many times and I have been reading all the answers around that, however this situation is further complicated because I have to use VS2010 for Silverlight/WP7 and VS2008 for Compact Framework.
I therefore need to use multiple solutions along with multiple projects for this.
Is there a suggested "best-practice" approach for managing this, I am aware that I can create the multiple solutions/projects using add-file-as-link functionality to maintain the project, however this becomes a manual process open to error which I'd like to avoid.
Has anyone had any experience with automating the build of seperate frameworks, for example creating and maintaining a single .NET project, but having a custom build action which tweaks the solution and project files automatically and building several output assemblies for the different required frameworks. I am aware there is an added complications with making sure the correct references are generated.
Is there an existing framework that achieves this, I've had a search around but can't see anything. Alternatively is there an appetite for the creation of such a framework?
This session from PDC2010 might help:
http://blogs.microsoft.co.il/blogs/arik/archive/2010/10/31/pdc-2010-3-screen-coding-sharing-code-between-windows-phone-silverlight-and-net.aspx
Microsoft have announced that the Portable Library Project will be available H1 this year - so it should be available real soon - maybe at Mix?
Until then, the best advice seems to be to create a SL 3 class library project for most of your sharing - WP7, WPF, SL-Web, .Net desktop - but you'll then still need to do something special for WM6 (but for WM6 I still need to do lots of special things anyway - like it still insists on using VS2008!)
I'm starting a new project which would greatly benefit from program add-ons. The program in its most basic form reads data from a serial port and parses it into database records. Examples of add-ons that could be written would be an auto-archive add-on, an add-on to filter records, etc. I'm writing both the program and the add-ons, but some customers need custom solutions, so instead of branching off and making a completely separate program, add-ons would be great. The simplest add-on would probably be a form who's constructor takes an object reference, manipulates the object in some way, then closes.
Unfortunately, I have absolutely no idea where to start coding, and almost as little idea where to search. Everything I search for turns up browser add-ons. From what I have gathered, I need to look into dynamic loading DLLs. Besides that, I'm clueless. Does anyone have any good resources or examples I that they know of?
I'm happy to provide more details, but this project is in its inception, so I don't have a ton of specific details (specifics kind of defeats the point of add-ons, too.)
You should seriously consider using the Managed Extensibility Framework (MEF) to handle your plugin architecture. It requires thinking about things a little differently, but it is well worth the mind-stretch.
This is a simple example to illustrate the basic technique.
codeproject.com - Plugin Architecture using C#
This article demonstrates to you how
to incorporate ... as a
plugin for another application or use
it as a standalone application.
in .NET 4 you now have the Managed Extensibility Framework (MEF) to do much of the plumbing.
In .NET 3.5 you had the System.AddIn but it was deemed by many to be far too complex.
codeproject.com - AddIn Enabled Applications with System.AddIn
AddIns (sometimes called Plugins) are
seperately compiled components that an
application can locate, load and make
use of at runtime (dynamically). An
application that has been designed to
use AddIns can be enhanced (by
developing more AddIns) without the
need for the orginal application to be
modified or recompiled and tested
You really need to look at Managed Extensibility Framework (MEF). This is specifically designed to help support add-ons and other extensibility.
A very basic description (basically, your plugins must implement a special interface):
http://martinfowler.com/eaaCatalog/plugin.html
Much better article, in C#:
http://www.drdobbs.com/184403942;jsessionid=TVLM2PGYFZZB1QE1GHPCKHWATMY32JVN
I think Reflection will play a major role.
I expirimented with an app that had a plugin folder. A filesystem watcher would watch the folder, and when a new DLL was placed in it, it would use reflection to determine which types of plugins it included, loaded them, and added them to the list of available classes, etc.
Try using the term 'add-in' or 'plug-in' for your research instead of 'add-on'. That should help some.
If you're using .Net 4, there's an add-in namespace in the framework that will get you partway there.
Writing plug-in support for an app is no simple task. You'll have to maintain pretty strict separation-of-concerns across your interfaces, you'll need to provide an interop library that defines ALL of the supported plug-in types, and you'll want to do some research into dependency injection & inversion of control, in addition to the previously-suggested reflection research.
It sounds like you might have a busy weekend doing research.
I have never been a fan of the windows command line. I have tried tools like powercmd and liked them, but most are not distributed for free and I don't relish the thought of paying for something that I think I could write myself. I want to write my own command line wrapper similar to powercmd that allows for these properties:
Custom fonts and colors
Opacity of windows
Multiple windows opened at same time in a panel (maybe like tabbed browsing)
Ability to resize windows
I am reaching out to you guys now to help me decide on whether I should attempt this with C# in visual studio or whether I should do it in Java with Swing. I am comfortable with both. Has anyone ever done a command line wrapper like this? If so what language did you use and what was your experience? Thanks for any feedback.
Grant-
If you want to do a windows command line, I would recommend C#. Java's enforced platform independence will make you fight too much to pass along commands to the underlying OS.
There's already Console2 that hits the big bullet points - resizable, opacity, tabs, modifiable fonts.
It's written in C++ and under the hood it wraps cmd.exe (or whichever command shell you tell it to use) so those may be two strikes against it if you're really interested in developing your own shell in a managed language.
Since you asked, I wrote one myself in C# - the Process class is just too useful. The main thing here is I/O redirection. While I never managed it fully myself, you need this so that subprocess output doesn't appear in another console window. You can also kill programs, find existing ones, etc.
Also, C#'s Console manipulation is very handy.
While I am not a Java programmer, I can imagine that both of those important features would be quite hard to use, considering that Java is platform-independent.
C# has several benefits over Java for this type of project, not the least of which is better integration with Windows, which is (presumably) the only platform you're developing this for. The Java Swing library is not nearly as fine-tuned looking on windows machines as C# forms tend to be, and with the ability to use WPF, C# seems the clear winner to me.
I would not use Java and Swing for this. C# will let you communicate directly with the .Net framework and allow you the ability to build a more powerful command line tool. IT will be a hassle to get Java access to some Windows System calls.
Just wanted to let you all know that I did end up writing a command line wrapper with C#. It turned out really well. I have a couple more little things I want to add and then I will put up the source code as well as a place to download the .exe. I posted a video of it in action in case anyone wanted to provide feedback or ideas. Thanks for the help.
http://www.youtube.com/watch?v=-NM-XcYwLDc