Related
I have a Xamarin.Forms App based on .NET Standard 1.4 that uses protobuf-net to store objects in the database that will be sent to a WCF service at a later time.
On Android and UWP "managed" everything works fine but - after searching through repositories, articles and blogposts that can no longer be accessed, and also after trying to get the precompilation tool to work, but failing at that - I have one simple (probably not) question: How do I get protobuf-net to work in "restricted" environments like UWP/.NET Native and iOS/Xamarin?
Right now I don't have a great solution for this scenario. I know some people have made it work, but I'm not expert enough in UWP / Native / iOS to give you reliable "here's the path to success" instructions.
UWP / .NET Native and iOS share (as you know) a common issue: lack of full runtime emit. I understand why this is. It is just: tricky.
Historically, protobuf-net has tried to solve this problem via a build tool that repeated the existing IL-emit usually done at runtime - as a build-time tool. This was ugly and nasty, but it worked. Kind of. To hack around some platform restrictions, protobuf-net used some of the IKVM tooling to help with this, but as the .NET framework scene has continued to expand this is basically not viable. Plus: the IKVM tool is now abandoned and won't be being maintained.
In parallel with this, there is increasing impetus to investigate some newer concepts:
full async/await for asynchronous IO sources: note that this is extremely unfriendly to IL emit, but is almost embarrassingly easy to implement in C#
"pipelines" / "channels" / "streams 2" - whatever it is being called this week; but: the new allocation-free IO concept that is being used in Kestrel (I helped kick this ball around a little bit when it was in the early stages, so I'm familiar with what needs doing) - note that this also ties into async/await
and of course: how all of the above relates to pre-generation
Right now, I'm very much of the opinion that the best route forward is for the pre-gen scenario to switch to emitting C# via build-time tooling. I have repeatedly petitioned MS for improved automated C# emit based on Roslyn, but so far: no joy (vexingly: the asp.net stuff even had a fully working proof-of-concept, but it is shelved). So right now I'm thinking: we need to assume that isn't going to happen, and basically write it independently. This isn't necessarily as complex as it sounds (and: codegen of various forms is very familiar to me). The advantage of C# emit here is that I don't need to fight the intricacies of every framework - I just need to make it compile (well, and run, obviously).
So: what's holding me back? In theory: nothing. I just need to get this stuff written and deployed. In reality: life, time, etc. I am guilty of prioritising things that impact me daily, and the reality is that I'm not really a daily user of those platforms, which means I'm not feeling the pain that you're feeling. But: I hear you loud and clear, and I am trying to ramp up the v3 work that should address these points. I genuinely want to have a good story for those things - and my aim is that by moving to a C#-emit model (for pre-gen, at least): it helps me. And if it helps me I know it won't be the forgotten toy in the attic / basement that I know is there but which it is hard to find the motivation to go to the trouble of finding.
In our company we develop and sell a VB6 application and we think it's about time to migrate it to .NET.
The main reasons are:
We expect VB6 runtime support to end at some point in time, and we do not want to start the migration just then since it's probably gonna be a lengthy process.
There is just 1 1/2 VB6 developers left. The half one being me.
More and more customers asking for features like cloud and mobile device support.
I know that rewriting an application from scratch is the least recommended way for migrating to .NET. I totally aggree with that! Throwing away over a decade of code feels just wrong and would be such a waste of money spent, that I have a hard time recommending and justifying it towards our management.
But right now I don't see another way to do it.
Let me tell you a little bit about the application:
Like I said it has been developed for over a decade. There have been numerous developers working on it, most of them rather unexperienced at that time. We have one developer left from the initial team. That application has been his first and biggest software project and by now he realizes that many of the architectural decisions made over last 15 years have been horribly wrong, others were right at that time but have not been refactored to meet changes made in other parts of the application and so have become wrong at some point in time. This application seems to be a showcase example of code rot.
We are talking about an application of about 150 KSLOC, all in one single executable. It uses about 15 external DLLs, some of them third party ActiveX controls, some of them are our own .NET assemblies.
Adding new features to the application is still possible and being done, but takes ages compared to our other .NET applications. The reason is that every little change in the codebase requires changes all over the place. The only reason why changes are possible at all is because that one developer simply knows most the dependencies and quirks of the application. As you might have guessed the rate of unexpected side effects and bugs is quite high.
My first thought about migrating that application was to first clean up and refactor, then migrate/convert possibly using tools from Artinsoft/Microsoft/WhoEver and then refactor again to get a nice and clean .NET application.
But I see some problems:
There seems to be no way of refactoring the old application. There is no automated testing whatsoever, not even a formal method for manual testing. Every little change requires manual testing by experienced users who just know where defects might hide.
on the other hand I have established a process and set of tools for testing of our .NET applications which gives us a solid base for making refactorings
Converting that code to .NET without major refactoring feels like: Garbage in, garbage out. Even though I hate calling the old application garbage because somehow it works and has proven itself useful.
Our management has a habit of explicitly demanding quick and dirty solutions, disregarding the effects it has on the productivity and against all recommendations from the development team which has at some point started to deny the existence of quick and dirty solutions in order to be able to do things right. That does not mean that we polish features, but we do include the time to write tests and do refactoring in our estimates. So knowing this, I suspect that once the code is converted to .NET and fixed to the point where the application starts and seems to work, the refactoring-phase will be canceled and the application will be shipped to some customers.
So. What I think is that, despite the fact that rewriting from scratch will take a lot of time and resources, it might still be our only option.
Am I missing an option? Do you see possibilities of not having to rewrite that application?
I suggest that you take a step back and read this paper by Brian Foote & Joseph Yoder (University of Illinois). It provides some architectural insight into the problem you have and options to solve it. It's titled 'Big Ball of Mud' (please don't laugh, it is a serious paper). Here is the abstract:
While much attention has been focused on high-level software
architectural patterns, what is, in effect, the de-facto standard
software architecture is seldom discussed. This paper examines the
most frequently deployed architecture: the BIG BALL OF MUD. A BIG BALL
OF MUD is a casually, even haphazardly, structured system. Its
organization, if one can call it that, is dictated more by expediency
than design. Yet, its enduring popularity cannot merely be indicative
of a general disregard for architecture.
These patterns explore the forces that encourage the emergence of a
BIG BALL OF MUD, and the undeniable effectiveness of this approach to
software architecture. In order to become so popular, it must be doing
something right. If more high-minded architectural approaches are to
compete, we must understand what the forces that lead to a BIG BALL OF
MUD are, and examine alternative ways to resolve them.
A number of additional patterns emerge out of the BIG BALL OF MUD. We
discuss them in turn. Two principal questions underlie these patterns:
Why are so many existing systems architecturally undistinguished, and
what can we do to improve them?
BTW, I think your best option is to use the current application as your Requirements and rewrite everything in VB.NET or C# using a proper design.
There are four main options when you have an application like this:
Do nothing: this is always an option, as everybody knows, if it ain't broke don't fix it. However this might not be an option for several reasons such as needing to comply with some security requirements at the company, or simply because one of the components doesn't work in new platforms.
Rewrite: This would be the dream, right? being able to get rid of all the bad practices and duplicated code and so on? Well, it might be that way, however you have to think all the risks involved in developing a new application from scratch. Do you have all the formal requirements? what about test cases? do your team know every little detail in the code or would you need to go line by line trying to figure out how why that if is there? Also, how many bugs do
Buy something off-the-shelf: Since you are an ISV this won't be an option.
Migrate: Of course you'll be bound by the programming practices you used for the original development but you'll get to a new platform faster, all your business logic will be automatically migrated, you can actually hire developers for the new platform and you can get rid of the legacy elements. From here you can also take advantage of all the tools available to refactor code, continuous integration, unit testing, etc.
Also, with an automatic migration you can actually go further than just WinForms. There are also tools that can take your C# code all the way to the web using a modern architecture.
Of course, I work for Mobilize.Net (previously Artinsoft) and this is my biased perspective.
We've been working on this for around 15 years and have seen dozens of clients who come to us after trying to re-write their application and fail after months or even years of struggling without being able to deliver a working application.
So I've been learning C# for like a year now (I'm 20 years old) and I'm getting pretty confident with it. I've also been meddling with C++ every now and again. For example just recently I've been following the Nehe OpenGL tutorials for C++ and I find it a fun way of learning.
I want to start looking at creating cross platform GUI software after I stumbled across this library called FLTK (fluid something rather). After finally and painfully getting it to work I found it refreshing to know that there are solutions for GUI creation in C++, however I think FLTK looked pretty old.
So I googled around for some newer GUI frameworks and decided to start playing with wxWidgets (decided against Qt because of licensing).
I downloaded it, compiled it, and looked to see if there were any IDE plug-ins for RAD development, as you can imagine going from drag and drop a component onto a form in C# I was hoping for something similar.
I learned that code::blocks has something of the sort so I tried that out. It was alright but the thing that turned me off was the horrible code completion; it would only show members and methods in the current object and nothing for the #included header files. I understand that code completion/IntelliSense isn't easy for C++ but Visual Studio 2008 handles it pretty good. I did find some other RAD tools like wxFormBuilder but it costs money, not something I want to do for simply learning.
So my TLDR question is if anyone has had experience with wxWidgets? Do you just develop in whatever IDE you're comfortable with and just code the GUI? Meaning no visual helpers? Perhaps you could give me a nudge in what direction I should be going :)
Thanks, this is also my first post on this site albeit I have read many threads before that have helped me solve copious problems. Cheers!
My suggestion is to learn how to do GUI layout with wxWidgets in code, then when you get good at it learn how to use the GUI tools.
Doing this kind of work manually for a while gives you the understanding about what you need ("Ok, I need a wxSizer, vertical, to put these two horizontal wxSizers into, where I put my a wxStaticText and a wxTextCtl for each line ...")... where as I think if you started out with the GUI tools you'd just tend to get annoyed because (last time I looked) none of them were Drag And Drop editors like you get with .NET.
Definitely give Code::Blocks another try. It is a WONDERFUL environment to work with wxWidgets in. It comes with a form designer and templates for wxWidgets projects, so I can't imagine working without it.
Also, for a good beginner's introduction to wxWidgets, try this page. It helped me alot when I started with it.
I use wxWidgets without using a drag and drop designer. There are obviously drawbacks to that approach but an advantage is that you don't have any horrible automatically generated code to deal with. In the past I've found having such code in the middle of my project has caused various types of grief - especially if you decide it needs some serious changes it is often necessary to start from scratch because form designers are so much better at "writing" as opposed to "editing".
For simple applications you can assemble a UI using a mixture of customized and standard widgets without too much difficulty. Check out the wxWidgets samples and demos, which use that approach. My chess app (see my website) uses this approach too.
A more elaborate UI could possibly be implemented by writing something special at a higher level of abstraction. The kind of thing I am thinking of would be a subsystem that accepts high level flexible requests to provide different types of user interface functionality, and then sorts out the details of the controls to create and the positioning etc. of those controls itself. That is kind of a technical fantasy of mine but I haven't ever really attempted to do it. Actually, a fairly primitive facility of this type is already available and used by the demos I mentioned; It is called a "Sizer" (class wxSizer) and is basically a control container.
Finally I would point out that problems with the Qt licence have basically gone away since Nokia bought Trolltech and made it "more" free (LGPL licence). Many people think Qt is the way to go these days. I am pretty happy with wxWidgets but will definitely evaluate Qyt seriously one day. Good luck with your projects.
I have developed a number of application GUIs using wxWidgets - you can see screenshots at http://ravenspoint.com/
IMHO, you should distinguish between designing a GUI and implementing it. Expecting to use the same program to design your GUI and to automatically emit all the code to implement the design is expecting too much.
A design program should be fast and simple. I recommend http://www.balsamiq.com/
Once you have settled on the design, then you can turn to the coding. Personally, I find that placing widgets on a panel using the wxPosition and wxSize parameters of the wxWidget constructors to be trivial - easier than trying to nudge widgets into their exact positions using the mouse.
The trouble with using some kind of form builder to emit all the code for a significant GUI is that you end up with a morass of automatically generated code that is hard to find your way around in. If the code has been handwritten, then you already know where everything is located.
wxFormBuilder but it costs money
wxFormBuilder is Free and Open source
Also Visual Studio is best for C++ coding in wxWidgets, but you will run into lots of issues on Linux due to the way Visual Studio handles a lot of things, like file names you have to take extra care for case sensitivity.
Also regarding the GUI, add the wxFormBuilder to the Visual Studio solution, add the file type handler to Visual Studio. Now just double click on it and add your dialogs, like you do it in C#.
Just add the generated code files to the Visual Studio project once and you are done.
It's very easy to use Visual Studio with GUI programming in wxWidgets.
Also don't forget to watch the CodeLite editor if you want to port on Linux. It is very much compatible with the Visual Studio projects and shortcut keys.
There is wxGlade and wxFormBuilder.
I don't know if there is another one, but the wxFormBuilder I know is free and open source.
You will find links to other tools on the homepage
of wxGlade (http:// wxglade.sourceforge.net/).
Most of these programs are able to output xrc files, which are are an XML representation of your GUI. It address the issue of complexity of the generated code but is not as powerful.
Yet personally I don't use any of these tools, except sometimes to see what it's going to look like before I do it but never to actually generate code.
I just finished doing a hello world program in both wx and fltk using the netbeans IDE. Microsoft Visual Studio WinForms or MFC was much easier than either. I needed cross platform capability so I could not use it for this application. I finished fltk in much less time than wx. The program was simpler, smaller, faster, and easier to write. Wx had pretty disjointed documentation and organization. Fltk was designed back in the "old days" when small fast and efficient was valued. That's probably why it seems "old" to you. I'm an old guy so it worked for me. YMMV
I recently started playing with C#, but I am finding it very frustrating. It seems every time I want to add what I think is a simple control, I end up either scouring the internet or writing my own. I just feel like I spend more time recreating controls to get them to work the way they should, and less time actually creating applications.
For example: In another question, I asked if it was possible to remove the border on a combobox; something I thought should be built into the control, but alas I had to build my own control for this simple alteration.
Am I just too new to C#/.net, or am I just expecting too much? I know SO loves C# so don't bite my head off for feeling this way, just help me understand what I am missing and whether I should continue learning and working with C#.
I spent 4+ hours today tracking down an 8 byte memory leak in a C++ program. There are threads involved and attaching the debugger would alter the thread timing so I couldn't do even something as simple as breaking on the Nth alloc to see where the leak was. Additionally I knew generally in between which two events the memory was allocated. Unfortunately both threads thought that was a great time to allocate lots and lots of 8 byte size objects. At the end of the investigation I found a ref count error on a COM pointer was leading to the leak.
Not having to pull your hair out over investigations like this is why you should move to C#.
For example. In another question I asked if it was possible to remove the border on a combobox; something I thought should be built into the control, but alas I had to build my own control for this simple alteration.
Of course you can't remove the border on combo boxes. They are Win32 controls and they have to play by the rules of Win32. That inlcudes giving the OS and the user, not the application control over styling.
If you want something you can style completely on Windows then you need to look at WPF.
I think what you really mean is:
Windows Forms on .NET is increasing my development time - am I missing something?
I think you are missing several things:
Open mindedness - with any new programming language comes not only new syntax, but new paradigms. If you come from C++ paradigms such as garbage collection may sound "too automatic" from you and you'd like to have more control but alas, you have to let go. Whenever you jump from one paradigm to another the prerequisite is always the ability to unlearn what you've always known.
Windows controls aren't the same as web controls - I've checked your previous questions and they look like you've been from VBScript, which probably means that you use it either from Office or ASP Classic. That being said your demand for controls that were easy to conjure when you were in the web would be much tougher for Windows -- Windows was not designed to be easily modifiable. That's why WPF/Silverlight was made.
Productivity is a function of ability to learn - There, I said it. It might hurt but, if you have cynicism or hostility blocking your learning process, you will simply not become productive soon. If you've been used to not having to learn new things, you will also not become productive soon. If you think you're really good at learning new things you will find ways to become productive in that language -- and then we can discuss about merits of your arguments vis-a-vis development time.
With any new technology there is a substantial learning curve at first, and some have a higher learning curve then others. I think you will see as you gain more experience that these things become substantially easier. C# has a lot of power with the .Net architecture to leverage from, but a lot of it takes time to really appreciate. C# is also changing and growing to allow for new coding styles (newer versions incorporate a lot of influences from functional programming) that keep it both in vogue and powerful. Stick with it and keep learning.
You're not the first, nor the last developer to have this sentiment. It always seemed to me that every time I needed to do something that wasn't part of a demo, I had to spend hours trying to figure out how to accomplish one small task. Much of my frustration was with ASP.NET web controls.
That being said, I found that once I got over the (steep IMHO) learning curve of control development, many of my frustrations were eliminated. I feel that using inheritance and overriding virtual members to create new behavior is a very clean approach. Plus, it creates output that can be very easily reused. Using OO practices just always seemed better to me than pasting JavaScript snippets all over the place.
Microsoft does a good job of providing many base controls to use out of the box, but every application always seems to need something that's missing. I would recommend learning control development, or looking to third party solutions if possible. There are many companies that exist solely to fill the voids. Either way, I wouldn't judge the whole language based off of the default control set.
It sounds like you are just new to it. It's not C# that's the problem it's the .net framework. If you used VB.net for example you'd likely have the same issue.
I went through this issue when I went from classic ASP to ASP.net. For half a year or so I felt the things I wanted to do in ASP.net were so much easier in classic ASP. Eventually that went away. Now I'm going through it again as I try to learn ASP.net MVC. Things I could do in 5 minutes in ASP.net are taking me days to figure out in ASP.net MVC.
In your case it sounds like you are using windows forms. Were you working with winforms before (i.e. VB6)? If you want more control over styling you might want to look at WPF.
Yes. You are missing something -- experience with the tools you are using.
For example, a few months ago I decided that my next project would be in ASP.NET MVC. I had been doing WebForms for several years and had dabbled with RubyOnRails for a couple of personal apps. MVC fit in with my desire to increase the testability of my apps and I prefer writing my own HTML for the most part anyway.
Despite my experience with ASP.NET, C#, and experience with MVC in RoR, it still took my awhile to match the velocity I had with WebForms. I felt like I had to spend all my time looking for how to do stuff. Now, a few months later I feel like I'm able to develop just as quickly as before. More to the point, I know the various paradigms and can apply them easily when faced with a similar problem to one I've solved before. I'm also building up a collection of extensions, snippets, and components that can be reused over and over.
I suggest that you give C#/.NET a chance for long enough to get over the inevitable early struggle and then decide whether it's the technology that's the problem.
Could it be that what you're trying to do is not, let's say, common? Most GUI developers follow some sort of human interface guidelines so that their application fits in well with the window manager of the OS being used. It helps with the user experience. Most GUI elements are designed with this in mind. So, it could be that you're trying to make your interface radically different than most, and thus, are finding that you have to do some custom work. That would be normal.
Depends on where you are coming from. I find c# to be very effective.
I rarely if ever use other controls as they often do not work 100% to my use cases and they create dependencies on your app.
So when you want to upgrade your project to c# 4 and can't because control X Y and Z don't work in c# 4 ... your SOL.
So I just take the hit up front and write my own controls which causes less grief later.
With some changes in the staffing at the office, the levels of C# expertise has dropped off precipitously and there are now more Java developers. It has gotten to the point where the higher-ups are considering moving an existing .NET project written in C# into the Java world.
Aside from the obvious problem of starting completely from scratch what are the possible ways that this company can accomplish a successful move of development on a project from .NET C# into Java?
Here are things to consider:
Is this big project? If Yes, try to stick with C#
Is this medium sized project with components? If No, try to stick with C#
Is this small project meant to be deployed on windows only? If yes, try to stick with C#
Is this old source code? If Yes, try to stick with C#
Do you use windows OS specific APIs? If Yes, try to stick with C#
Do you use any third party APIs without Java counterpart? If Yes, try to stick with C#
Do you use .Net in "deep"(data binding, User controls etc.)? If yes, try to stick with C#
Migration time is more acceptable than getting new/converted C# guys? If no, try to stick with C#
Do you think end users will not be receptive of changes, if you are to use Java framework which will change presentation? If yes, try to stick with C#
Check commercials
If you decide to convert:
Go per component
Go per layer
Have lots of tests
Check if there are tools to help (however small help may be) with migration
Just to add to Brian and Eric's opinions, I would say that picking up C# for a Java developer should be straightforward in my opinion. They are conceptually very similar languages and I would suggest training your Java developers to gain some C# skills so you won't be forced to go to the hassle of a migration process.
I subscribe to Joel's view that a total rewrite is almost always a mistake. Other posters are right: C# and Java are similar enough that any competent Java developer should be able to become competent in C# in a matter of weeks or months. That's not to say they will be experts. That takes longer but as long as you have some C# developers who can guide the process then you should be OK.
It's hard to comment on whether or not such a transition is a good or bad idea without knowing specifics of your application: size, type of application, industry and so on.
I would be extremely reticent about such a switch because, in my humble opinion, C# is now a much more modern language than Java and I say this to you as someone who has been a Java developer ofr over a decade (since the 1.0.2/1.1 days).
That's not to say that Java is bad. It's not. Sun does have a cloud hanging over it and demonstrated an unwillingness or inability to drive the platform forward in recent years.
Regardless of the languages involved, the management of this company sounds insane. For anything other than a trivial application, how can it be economically sensible to rewrite an entire code base from scratch instead of just hiring a single person with some skills in the right language? Is this a business with that well-known problem: too much spare cash?!
How long has the existing code been in development? If it's barely started, I could understand this. If it's seen a release and has active users, it will never make sense to throw it away. If you donated the C# code to a start-up with the right skills, think how much of a head start they would have over you.
Before you finish converting the .NET project into Java, all those Java developers who were part of the conversion project will have learned C#. So then you don't anymore need to convert it to Java (and you can throw away all Java code which was produced in the conversion), because now you have a development team which can do both Java and C#. Problem solved. :D
Have a look at Net2Java, which puports to assist in converting your code from C# to Java. I doubt it'll be perfect, but its one way to remove a lot of drudgery from the task, leaving you with the kinks of incompatible framework calls and language features to iron out.
Once you've done that, your task is like any other large migration project - test, test and test again. Unit tests, System integration tests, then end-user tests. You should havew those tests already in place that you used with the original application, apart from the unit tests, they will still be relevant.
If there are any components that are already isolated or any of it uses a service-oriented architecture, you could conceivably migrate one component at a time (where each individual component is a rewrite) and still have the components talk to one another using the same interoperable network protocols. Probably depends on what type of app we're talking about.
Make sure you have tons of tests, because such a migration will bite you where you expect it least.
Do you have more .Net or more Java applications in production. If your already have a substantial investment in .Net servers and applications, why not ask for volunteers among the Java developers to move to .Net? The language and syntax is very similar, so the hard part would be learning the framework and unless they would spend all their time doing UI development even learning the framework is not that hard.
In our office we have a number of very good developers who move back and forth between Java and .Net as needed.
I am not a Java expert, but from my experience working with Java code whilst being a C# fan, the following are some of the possible headaches:
Generics are implemented differently in Java and C#.
Boxing/Unboxing behaviors are different between Java and C#
Java class naming convention + lots C# generated code
String handling (i.e. Unicode/ASCII concerns) can be problematic depending on the quality of Java/C# code being ported over.
Personally, I don't think writing from scratch is a bad idea at all. Since you already have a working architecture.
In order to prove to management, you always needs to talk in terms of ROI and numbers. Show them that if you move these applications, it will take tremendous amount of time, QA resources, and can easily take a back seat if it gets de-prioritized due to some other project or new development taking importance.
I had success when I showed them the timelines, ROI, work involved, money involved, etc.
So now coming to the actual point, I do think Java developers would be able to support C# unless they have some fundamental mental block against Microsoft technolgies.
Possibly you could use jni4net - opensource bridge ?
Or list of other options I know.
I'm somewhat surprised noone even suggested the idea of rejecting migration.
I do not believe a C# developer can be forced to switch to Java (or vice versa) because he was told to (well, if he's threatened with a gun then maybe). I takes much time, exercise and passion to master at least one technology stack. You just can't start overnight with a new technology and expect to provide the same quality.
I'd personally not bother until told to start migration. At which point I'd tell the manager that I'm .NET guy and won't switch to another technology just because they decided to.
As for the technical side, it's not the language syntax that differs but rather libraries and their features. Of course, if all the latest bells and whistles of .NET 3.5 have been extensively in use then the language difference will provide you with a real challenge.
That's certainly a funny way, just decide to migrate applications from .NET to Java. Someone has no idea of the hassle involved...
I realize that this is an old question but to anyone else going down this path, you could try this open source C# to Java Converter:
http://www.cs2j.com/