I am creating a class diagram in Visual Paradigm and I am struggling with one thing. How do I specify that a class is in fact a form. So when I export the diagram to code, it wont become a normal class but instead it will become a form. A form which can hold buttons, ListBoxes, etc.
Thank you!
You intend to specify in your Visual Paradigm (VP) diagram a dependency on Form which is a class available in the .NET framework.
It seems there is no clear explanation how to do that specific operation in the VP documentation. However, there is an article that covers the topic with Java SE classes. This article uses the Java platform sources (available as a zip file in the JDK since Java 6) to extract the classes in a specific project. Then the reversed project is registered as a referenced project in your model project.
It seems this is possible to do a similar operation with .NET dlls instead of Java sources (have a look at the linked article - the screenshot for step 2). For that you have to identify the relevant dll(s) in your environment: I guess the Microsoft .NET framework, not Mono. According to a Microsoft documentation, the appropriate file would be something like System.Windows.Forms.dll. You should be able to find that file in your environment. On the identification of the relevant dll(s), I can't help you further (being myself a Java developer working on Linux).
Beware: your library project should be quite important as you will have all the dll classes represented. This is probably the reason why the documentation makes the reversal in a separated project and not in the real model project (another reason could be the possibility to use the classes in other projects).
Related
I am developing a project using VS2013 that will target WP8, WinRT & Windows Desktop platforms on x86 or x64 architectures.
This project requires local data access / storage and I have selected SQLite.
I wonder if anyone can point me towards resources / blogs / samples that will show me how to create a data layer that will allow me to target all of the above while still keeping as much of a common code base as possible for my data layer?
I have the vsix extensions for each of the SQLite "flavors" and also the C# wrapper, System.Data.SQLite.
Many thanks in advance,
Richard
You are going to have to create a Portable Class Library that can be used by all of those platforms.
In that Portable Class Library, you will need to use an interface and you will have to pass in the platform-specific implementations (WP8 and WindowsRT will require slightly different implementations).
But here is what helped me. There may be some other resources, but this was definitely the best one and the one that allowed me to do exactly what you are looking to do.
It's a series that I followed (and made a few changes along the way) but it helped me immensely.
http://nicksnettravels.builttoroam.com/post/2013/06/02/Windows-(RT-and-Phone)-and-Sqlite-(Part-1).aspx
Here are some snippets from Part 4 the series:
create a separate SQLitePCL project and to define a set of interfaces
which map to the classes/methods which is exposed by Sqlite-net. I’m
not going to bore you with the details but you can see from following
image just a couple of the interfaces which will map to classes such
as the SQliteConnection, TableMapping and Column.
Regarding the Platform implementations:
For each platform we need to implement these interfaces. This is
really a matter of taking the sqlite-net classes, defined in SQLite.cs
and SQliteAsync.cs and modifying them to implement the defined
interfaces. This isn’t quite as simple as adjusting the class
signature to include the appropriate interface but it isn’t far off.
We need to create a separate class library for each platform, eg
SQLiteWinRT and SQLiteWP8. It doesn’t matter which platform you start
with (I did the phone implementation first) since you’ll be
referencing the same classes using the “add as link” technique
discussed in the previous post. You might be thinking, if we’re simply
going to be adding the same classes to both libraries why they can’t
be all in the shared PCL. The answer lies in the conditional
compilation statements at the top of the sqlite-net files – these
determine how the classes are built for the respective platforms.
I'm developing a TypeScript code generator that will use custom attributes on C# classes to generate TypeScript definitions and code files.
I'm considering two options for TypeScript code generation / source file analysis:
Reflection on compiled assemblies
Roslyn CTP
The tool would use custom attributes on properties and methods to generate a TypeScript file. Right now I'm not planning to convert the C# method body to JavaScript, but in the future this may be done. So for this reason I am seriously considering Roslyn. However to simply generate the outline of my TypeScript classes I think I could use reflection and custom attributes.
I am wondering:
a) Does Roslyn provide functionality that is impossible with Reflection? My understanding is that I cannot get method bodies with Reflection.
b) Would the Roslyn CTP license prevent my from distributing the tool under an open source license? This is not clear to me after reading the license
I just did something along these lines - works great for creating your datamodel in Typescript from your c# classes. I built it to generate a single AMD-module with an interface which mimics the basic data of your Models. Also supports Generics, and creates a class with Knockout properties, including a toJS() method and an update(data:Interface) method to update your class.
The whole thing is just a single T4 template. If anyone finds this and is interested: http://spabuilder.wordpress.com/2014/07/31/generating-typescript-from-c/
Also honors [KeyAttribute] and [Timespan] attributes for data models if you are using data annotations.
I've been messing around with generating js, and I'm finding Reflection to be a better tool for this. I'm basically pointing my generator at the bin folder of the project which the metadata comes from. There might be some difficulties with loading all the needed assemblies, and caveats with versions of assemblies in the bin folder, and versions of the same assemblies that your generator project references. But once you get over all of this, which I did with minimal difficulty, Reflection is a lot easier to use, and more reliable.
With Roslyn, you are basically just parsing c#. Roslyn does this very well, but I'm hesitant to switch to it from Reflection. With reflection, you get metadata more reliably.
Let's say you want the Prefix property of a RoutePrefixAttribute that decorates a controller class. If you're parsing c#, you may have:
[RoutePrefix("stringliteral")] or [RoutePrefix(constantString)]. So, you have to worry about whether it's a literal or a constant expression, then find out how to get the value of a constant expression, worry about all the different ways in which you can pass parameters to an atatribute (for example, will this break your code: [RoutePrefix(Prefix="literal")]...
Once you're dealing with the actual runtime objects with reflection, everything is just easier. You have a nice RoutePrefixAttribute object, and you can go routePrefix.Prefix to get, reliably, the value of the prefix.
This is just one example of how doing things with Reflection is easier. It's the difference between gathering metadata from a set of c# objects in a type-safe way, and scraping data from c# code, albeit with a really nice scraping tool.
EDIT: Since writing this answer, I've bit the bullet and switched to Roslyn. It's fairly powerful once you get the hang of it, and I did find one big advantage: you can get a reference to the workspace from a visual studio plugin, and easily do all kinds of stuff within the plugin.
Update Nov, 2018
The accepted answer is valid because it's dated in Aprl,2013
Now roslyn is distributed under Apache License Version 2.0
excerpt from the license:
Redistribution.
You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You meet the following conditions:...
Roslyn have a number of nuget packages
Doesn't the license only forbid you personally from distributing the binaries? It doesn't forbid you from adding a dependency from your NuGet package to the Rosyln CTP NuGet package. You personally cannot deliver the bits, but you can have NuGet pull in Roslyn automatically.
So just avoid checking Rosyln source or binaries into your version control.
The Roslyn website not clearly states that:
The current license is for evaluation and preview purposes only and
does not allow redistribution of the Roslyn binaries. Sharing of
sample projects built on the Roslyn APIs is permitted, but sample
users must have either the Roslyn CTP or the Roslyn NuGet package
installed in order to build and run.
I wouldn't use the current Roslyn CTP - simply because there will be new versions in 2014 and those will bring many breaking changes for sure. So you might end up with totally deprecated code.
(There recently was a blog post on this by a MS team member, but I'm afraid I currently don't have the link at hand.)
EditThere's a good chance that Roslyn then will get a license that also permits for commercial use...
Update - July 2015
Roslyn is still in CTP, but their FAQ on GitHub is much more to the point:
For sample code or learning purposes, the recommended way to redistribute the Roslyn DLLs is with the Roslyn NuGet package: [url:Microsoft.CodeAnalysis|http://www.nuget.org/packages/Microsoft.CodeAnalysis].
So it appears that you still cannot redistribute the DLLs in finished products. The project will need to be open sourced and the solution will need a reference the NuGet package.
Original Answer (November 2012)
I don't believe you can distribute under open source.
6.DISTRIBUTABLE CODE. The software contains code that you are permitted to distribute in programs you develop if you comply with the
terms below.
6.c Distribution Restrictions you may not modify or distribute the source code of any Distributable Code so that any part of it becomes
subject to an Excluded License. An Excluded License is one that
requires, as a condition of use, modification or distribution,
the code be disclosed or distributed in source code form; or item
others have the right to modify it.
At first it sounds like you could do it if you just include the Roslyn binaries, but the Distributable Code definition specifically says "The software contains code..." and I believe that is what everything after is referring to.
To your other question, Roslyn isn't fully finished and is still Beta. I don't know exactly if it is currently in a state that allows it to handle your needs. That's something you may just want to spend a couple of hours tinkering with. I wouldn't think it had more functionality than what .NET currently allows. You can see what they recently added in September here and what is currently not implemented here.
For my experience using T4 generations based on reflection, as TypeLite does, is somehow simpler but has some drawbacks, like once the project depends on the classes that have been generated, regenerating them with a breaking change (renamed a class) will lead to a non compiling project so running the template again will output a blanck file and the user will have an hard time making everything compile again.
So, having the same need, i started experimenting with Roslyn, and it seems very promising, but i have many doubts on how to use it properly...
You can take a look at what i'm doing and maybe help me here: https://github.com/TrabacchinLuigi/RoslynExporter
I have a class library that targets .net 4 and is used across different platforms via Mono.
I now want to port it to be used by Windows 8. I know the name keeps changing but this is currently called a "Class Library (Windows Store Apps)" in VS2012.
I initially started with trying to port everything to a "Portable Class Library" but this was proving too difficult as some things simply didn't have a generic approach that would work on all platforms targeted, and other things that were supported simply weren't available to the compiler.
So I've created a Windows Store Class Library and created links to the existing files of my standard Class Library so updating once will update both. I am planning on using pre-processing directives to make changes between the two class libraries
E.G
#if NETFX_CORE
Task.Delay(someTime);
#else
new System.Threading.ManualResetEvent(false).WaitOne(sometime);
#endif
My question is if this method seems a sensible approach? I have the same default namespace and assembly name. Could this ever cause issues to my compiler? The assemblies target different platforms so would never be used together in the same application but do both sit in the same solution in Visual Studio.
Overall, yes that should work. That specific case is a poor example, because the two implementations function very differently, illustrating that you may need to rethink some aspects of your design. For cases where there is a similar API swap (with similar semantics), I personally tend to move the difference behind a helper method, so my "main" code doesn't need to worry about this - just the helper code. Reflection would be a good example of this (the changes to reflection are annoyingly deep).
The two projects with different target platforms should be fine. I occasionally hit an IDE glitch where it complains about temp files. I think this is due to sharing files between projects. I've logged it on connect
Try
Task.Delay(msDelay).Wait()
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've been looking around for different methods of providing plug-in support for my application. Ideally, I will be creating a core functionality and based on different customers developing different plug-ins/addons such as importing, exporting data etc... What are the some methods available for making a C# application extensible via a plug-in architecture?
Lets make up an example. If we have a program that consists of a main menu ( File, Edit, View, et al. ) along with a TreeView that displays different brands of cars grouped by manufacturer ( Ford, GM, for now). Right clicking on a car displays a context menu with the only option being 'delete car'.
How could you develop the application so that plug-ins could be deployed so that you could allow one customer to see a new brand in the TreeView, let's say Honda, and also extent the car context menu so that they may now 'paint a car'?
In Eclipse/RCP development this is easily handled by extension points and plug-ins. How does C# handle it? I've been looking into developing my own plug-in architecture and reading up on MEF.
MEF would be a good place to start.
Glenn Block's article Managed Extensibility Framework: Building Composable Apps in .NET 4 with the Managed Extensibility Framework provides a good overview.
BTW, don't be fooled by the title - you can also get MEF for .NET 3.5 SP1.
Visual Studio 2010 uses MEF, so I think its a safe bet this is the preferred way to go at MS. System.Addin always seemed a bit heavy, but it might be a better choice if you need addins to always work and your codebase is constantly evolving.
If you care about isolating addins, you should read up on AppDomains. I've got a demo project which I made to help learn how to deal with isolating assemblies within an AppDomain here, which you might find interesting. Quick facts about isolation: Only your types should ever cross the boundary and these types should be sealed, run screaming from cross domain event handling, and addins should NEVER extend MarshallByRefObject.