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 4 years ago.
Improve this question
I am attempting to create my own version of a cryptocurrency by using a BlockChain in a P2P network. I would like users to access my website then download an executable that allows them join the network and mine for currency. I also would like my website(c#) to display the updated ledger of the blockchain. I have done a lot of research, with little success, attempting to understand how to construct the P2P network.
What would be the recommended language to construct this executable? Are there any tutorials or examples that are suggested? In addition, how would my website access the universal ledger? Is it feasible to have my website's server also join the P2P network, or should the P2P network continuously send the ledger to my server?
I believe this is language agnostic. Any language that can be built on different platforms. Actually, I saw a book about blockchain implementation in python. But also there are courses on Java.
Blockchain is a very complex technology to understand not to mention inventing something like that with C# language.
I might want to start with Ethereum which uses solidity language similar to JavaScript.
If you would like to use C#, you might want to look at Nethereum (.Net integration library for Ethereum).
As Dmitry mentioned this is language agnostic.
Regarding C#: we have Bitcoin and Stratis full node implementations in .NET, which may be your best reference. As Win said, it's a complex technology, so expect years of development until you can roll out a buggy alpha version, assuming you are doing it alone.
You may also want to get some experience first, for that, take a look at the book: Programming the Blockchain in C#.
Then go and try building your product based on the above mentioned reference implementations.
What would be the recommended language to construct this executable?
Historically lazy altcoin devs just cloned Litecoin and changed some parameters so C++ is what most alts are written in, but again: it's language agnostic.
In addition, how would my website access the universal ledger?
That's your smallest problem. If you succeed to roll out an alt, then by the time you will know it.
The choice of language depends on networking requirements and validation requirements.
For a completely decentralized use case, faster cryptographic verification is a need & thus languages native to the machine offer a speed advantage (like c++, golang).
If there is any element of centralization like private blockchain, permissioned blockchain, premined, asset-backed token, virtual machine blockchains like evm, colored coin etc. then access control and development requirements overtake permissionless and security requirements & thus language with available human resource should be chosen like c#, java etc.
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 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 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 8 years ago.
Improve this question
I've started looking into a few larger server-app frameworks that would be able to support desktop client interfaces as well as web interfaces, and have really zero'd down on the two obvious ones: J2EE and .NET. From a language standpoint, feature standpoint, portability standpoint, etc...I am pretty comfortable with my understanding of the two products. I'll keep it simple in saying that for the most part, either would fit the need well enough based on my initial analysis.
Where things are a pain though is in finding a good comparison from engineers who have spent a better part of the decade working with one, the other, or both. The undocumented frustrations that youwont get from Sun, Microsoft or a book.
A Google search turns up plenty of results, but most are from 2002-04. Suffice to say, plenty has changed since. J2EE is suposed to have gotten a lot simpler and .NET is supposed to have gotten a lot more feature rich.
Is anyone aware of more current comparisons (in the last two years) that might be worth reading?
Have you seen these?
http://en.wikipedia.org/wiki/.NET_Framework#.NET_vs._Java_and_Java_EE
http://en.wikipedia.org/wiki/Comparison_of_the_Java_and_.NET_platforms
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java
Since you say 'desktop' before you said 'web', i can assume that the desktop side of this application is more important. .Net has a definite advantage in making desktop apps, Java really doesn't have this as an advantage.
Having said that, i'd just go with whichever your dev team has more experience in.
Java EE has certainly changed a lot. The biggest changes that you'll want to be aware of are Spring and the new EJB3 spec.
Spring is not part of Sun's Java EE standard. It's the crystalization of Rod Johnson's consulting experience into a framework for POJO development that's gotten a lot of traction. And, just for reference, there are versions of Spring for both Java and .NET. Likewise for Hibernate, a popular ORM tool.
EJB3 has taken a great deal from Spring and Hibernate. You can use EJB3 with Glassfish or JBOSS or WebLogic.
Another idea that you'll want to keep in mind is web services. These are distributed web components that can work with any client, Java EE or .NET, desktop or browser. I think their chief benefits are the emphasis on messages and hiding the back end implementation details. If you write web services, your clients don't have to know or care whether they're written in Java or .NET.
Web services work well with rich Internet clients like Flex and Silverlight. They can help to keep your options open.
Sorry, I can't speak from personal experience about .NET.
This is a real "apples and oranges" type question.
Generally speaking I'd rather do desktop development in .Net. If I did it in Java I'd probably favour Eclipse SWT or Netbeans RCP over Java Swing.
For serverside programming you can use either. I'm not a huge fan of Windows as a server platform (over Linux) and the Java stack is essentially free, which is particularly useful in terms of start-up costs (Bizspark notwithstanding).
The biggest thing about Java server apps isn't really J2EE anymore. It's Spring. You'll probably find more Java web apps running with Tomcat and Spring than you do full J2EE stack apps (generally meaning including EJB).
EJB3 has gone POJO like Spring is.
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 7 years ago.
Improve this question
There is a group here using Java, server-side and client-side, with Swing for the client UIs. I plan to suggest that they change the front end to C# and WinForms or WPF, but I want to come prepared with:
A list of benefits to be had from moving to Winforms / WPF from Swing.
A list of Swing benefits that might get thrown back at me over using WinForms / WPF (the only one I can think of off the top of my head is the ability to share more code across server and client due to being the same language - given the fact that the server side will stay Java).
I'll preface this by saying I'm a .net developer so the following might be heretical.
It sounds like your company already has a significant investment in java. People, software licenses, and code base.
If my company (or group) was primarily java and we were successful in meeting business demands, then quite frankly there would be no way I'd switch.
The only way I'd consider switching technology stacks is if the stack we were on was truly dead. Meaning that it was very difficult to find programmers for, it could no longer meet business needs, we had a high number of failed projects, and/or the language itself was no longer evolving.
Switching just because someone prefers one language over another is non-starter and ultimately wouldn't make any business sense. The very act of a change like that will mean that the company is going to lose those people who are still committed to the old stack. Replacing people is extremely expensive just in terms of knowledge lost.
Another thing, if you don't already know what the hard reasons are for switching platforms then you shouldn't even try to encourage it. Take the accountants point of view, what really would this provide?
1) Swing stinks. (Almost just kidding, but really, in my opinion, it's pretty awful.) Even if you're going to develop in Java, use SWT or some other decent looking/behaving toolkit. Moving to Windows Forms or WPF will (potentially) give you a lot more powerful user interface options on Windows, but only on Windows.
2) You're tying yourself to Windows, and losing the cross platform nature of Java+Swing. You're potentially losing some ability for shared code. You're having to redevelop in non-java, which may mean a lack of experience/training/knowledge on the part of other developers on your team.
Performace & startup time. You just can't compare Swing to Winforms/WPF in the performace/startup time aspect.
Really don't know... if you have a high qualified Java team that does not know .Net APIs, stick to Swing, otherwise, don't think twice... Use Winforms. About "the ability to share more code across server and client due to being the same language", don't bother... there is zillions of ways to make two different applications from different languages that each other.
The performance of the GUI should be faster with a .NET winform app compared to a Swing app running on Windows. It's not really a huge difference at this point for most apps though, computers these days can run Java pretty fast.
Either way you would still be talking to the Java backend code. Depending on what they've done you may be better off just sticking with the Swing front end.
If it's an option you should think about a web front end. If it can be made in XHTML/Javascript/CSS, you would retain the cross platform benefits that the Java GUI gives you.
But really, you need to think about why you want to change to Winforms instead of Java. Is there something about the existing Java app that you don't like that would be better and worth the cost of redeveloping in another language? Is it something that can be fixed without a full rewrite?
Do you have any custom components which would be a pain to migrate from Swing to .net? Do you have staff that are expert at developing custom Swing components (Java2D expertise, familiarity with Swings input subsystem etc.) who know little about WinForm custom development?
If the answer either to these questions is yes then you should probably stick with Swing.
1) It is easier to make a Winforms app feel like a Windows app. Java applications usually feel "funny" if you aren't careful.
2) Everything you are programming is using Java. Having one component that is not Java means that the project is harder to work with. Overall maintenance will also be more annoying. Currently, everyone on your project team needs to know Java only in order to be able to work with anyone else on your project team. From a recruiting and maintainability perspective, this is convenient. Personally, I be against switching the GUI unless you were getting some other benefit out of it.
You have not provided any reasons why you plan to make your proposal.
If using windows .net is the better choice because yo have:
1. Good designer in Visual studio, good documentation and examples
2. Better startup, CPU and memory usage at runtime: see http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx
If using Linux, you have Mono versus Java, but it is more complicated to make a comparison there due to the large number of distros.
The big advantage are free libraries you can use in java.Most of the nosql systems are written in java , the best of all Neo4j (only java will give you ability to run these products embedded). This is something dot net can't do, and these will give your applications ability no winforms, wpf can have.
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
What's the best approach to Licensing Custom .NET Components or applications for selling ?
Closed Source
2 licensing mode :
Trial limited features license (free)
Full featured
As for a "Closed Source" scenario consider using obfuscation. I've been using SmartAssembly and very satisfied with results.
As for licensing modes. You are speaking about .net components so the target audience are developers. I don't think they will deal with free limited trials. If you are going to sell something valuable to developer community get ready to see a "Full Featured" version on Rapidshare or torrents.
I would recommend concentrating on support and frequent updates/enhancements rather than protection. In most cases "business" buys support rather than binaries.
If you need some tool titles why don't you just google for that? ".net licensing" query will give you tones of links.
Hope that helps.
There is a lot of missing detail here.
Are you licensing from someone or trying to create a license?
Open source, closed source, selling? If selling, do you provide source?
What is the final usage of the component / application? Are you hosting it (like a multi-tenant site) or is it more COTS?
What are your competitors doing with their sales model? Does it appear to be working for them? e.g. does it sound reasonable? <- emulate that.
As you answer those questions, you'll find the license that fits your needs.
GPL. Or declaring it public domain. Or a 24-page EULA that restricts the ability of users to shave while using the component. Or something like that.
Why don't you tell us what you are trying to do, what the intended uses are, and what you'd like to have happen?
When you're giving out trials of your software that are upgradeable to full versions (in other words assemblies that contain all features), there's not a whole lot you can do to prevent someone from hacking it in the end. (with .net it's even easier then with native assemblies).
Signing & Obfuscation is the only way to prevent it from being reverse engineered in a very readable form but just using something like reflector will basically give you the complete.
One of the simplest ways to keep up the appearance of licensing is to:
use public/private key encryption to save licensing information (expiration date, enabled features, etc) into a file
include the public key in the assembly
decode the encrypted information on the start of your application to check if someone is licensed to use your application.
generate licenses when necessary with your private key and distribute those files (or keys if the data is small enough)
As an alternative you can include the licensing information in clear text with a hash code (this is the licensing key, algorithm should also support public/private key) in clear text with the application, and only check if the licensing information matches the hash code.