As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In java world you have log4j and a a pretty decent logging framework, is there anything like that for C#/.NET?
log4net would be the obvious answer.
http://www.nlog-project.org/ - NLog
It's a very flexible and configurable logging tool that's very light-weight. You can set it up to log to many different locations (Console, SQL, File... etc). Very easy to use.
It's even used by Rob Connery in his Storefront MVC project... http://blog.wekeroad.com/mvc-storefront/
If you are looking for a simple non-bloat solution (the download is only about 100K and the actual dll about 40K), I've successfully used BitFactory on a number of projects.
It's small, configurable, reliable and free!
Try the Enterprise Library Logging Application Block
Even though I have used a few others mentioned here too - it is worth looking into.
There's also nLog, which is rather similar, but a bit more lightweight with less configuration.
The comments here seem to agree with Developer Dude and nzpcmad, as do I. Use Bit Factory, also called The Object Guy's Logging Framework.
As I've said in a few other places, I agree with others here about The Object Guy's Logging Framework. Like Developer Dude says, it isn't bloated -- like some other frameworks out there. It works in all our production applications--and has been doing so for several years now.
We've always used the MS P&P Enterprise Library Logging Application Block. It's not particulary cool or elegant, but it is pretty flexible and well designed. Main reason I think we use it is that we use a lot of the other components from the EL, and they of course all have dependencies on the logging module. More Info Here.
No doubt, try: this. Hands down, it is the best for most applications. It isn't bloatware.
Yep. Log4Net.
I've been using it for a while, it has been a life saver!
NLog is a good option.
I'd still say Log4Net is a safer options. Many other open source projects also use it, if you ever include one that does, then you've just reduced a dependency.
Is there anything that the Windows Event Log + Log Parser can't do for you?
Actually, if you don't need sophisticated logging options straight out of the box, I would suggest writing a thin interface that defines your logging needs (such as log.debug(), log.error(), etc). This will give you flexibility if you need to change latter, or find problems with your current implementation.
While this doesn't seem like a big gain, it was a big win for us recently when we ported our framework to the Windows Compact Framework, and none of the logging options worked. We were able to slide in a null logger, which saved us on that platform. Of course, evaluate for your specific project and needs.
Look at TraceSources and TraceListeners. It is built into .NET and configured with the config file.
James Newton-King covered log4net vs. Enterprise Library Logging about a year ago, and I think it's still largely up to date. My experience has been with EL only, and it's had ups and downs. It's a lot of configuration in a multi-tier application if you don't take advantage of every bell and whistle, so I'll probably try log4net on my next project.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Basically I have to choose a project methodology.
The components are not big (we develop components mainly for SAP connecting), however the team is rather big , dislocated and and very unorganized.
Besides how big is the team
which other questions should be taken into consideration?
Thank you
I've made very good experiences with answering these questions first:
How does the team prioritize work?
(I would recommend putting todos into a sequence building a backlog)
How does the team track what needs to be done?
(I would recommend breaking things down step-by-step into User Stories and track them using a tool like PivotalTracker)
How can you make sure the team is self-organizing?
(Let the team pull work from the backlog, run daily status meetings and a retrospective every couple of weeks)
How can you optimize how fast features get delivered in optimal quality? (This way of thinking should replace the idea of maximizing capacity utilization)
How can you make the work visible? (Visibility builds trust and momentum - you can start collecting metrics and putting up a screen showing all kinds of graphs)
One very useful question to assist in choosing any sort of method is "What projects can this not help me with?" It can be very difficult to obtain an answer; the usual way that supporters of a particular method respond is "of course method X can help you with any project." Thus they are saying either that all projects are the same, which is obviously not the case; or that they don't know what are the limitations of their method, and so will not be able to recognise when their method is not appropriate.
You say your teams are fairly unorganised. One of the best ways of introducing any new method is to provide tools - even very basic tools - that make it easier to follow the standards than not. An example of this was trying to improve the quality of development reports in a very large organisation - we provided a number of word processing templates, that made it easier to write a report using the templates (and hence the standards) than to write the report from scratch.
Personal note on my choice of language: I have worked with software development methods for many years, and to me "methodology" is the study and comparison of different methods. A particular way of, for example, managing a project, is a method, not a methodology.
I guess this really depends on a number of factors, for instance some contracts require you to use PRINCE project management which is rather complex.
If you dont have any external factors regarding the methodology you choose I would just do a bit of research and see which you think fits your team best.
I havent had chance to use Agile yet although I took a course on it and I liked what I heard, it seemed fairly straightforward which is a bonus.
One thing to remember though is you dont have to stick to one methodology if you find something isnt working for you then make changes.
Questions I would consider though would be the length of the project, Size of the team, Are the team each working on individual parts of the project or are there multiple people working on the same area, Time it will take to implement a methodology, Any costs involved?, Any training involved?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I came across stateless, a hierarchical state machine framework based on Simple State Machine for Boo, but configured using C# 3.0
It is easy to configure and use, I will probably use it soon.
But I was just wondering if
Anyone used stateless for real projects (If so what is your opinion?)
Are there any other good workflow engines for .NET? (other than WF)
I've been using Stateless and WF for an app that is intended to go into production someday. :) I have detailed my experiences so far on my post here.
Overall, I prefer Stateless because it's simpler for more things that WF. Sure, it's nice to be able to design your workflow graphically, but when you need to implement something more difficult than a sequential workflow (like the state machine workflow), you'll need to work with ExternalDataExchange just to make the right state transitions. It's probably not hard, but considering that and the fact that you need to implement a persistence service to pause a workflow just seemed unappealing to me. I don't have a need to persist a workflow to disk for later execution anyway... so I will be using regular events to deal with this in Stateless. Error handling is easily doable in Stateless (I've been successful with it), but the implementation I've taken is questionable, and is the topic of another discussion (which I'm searching for now on SO!). I might be posting a question regarding this very soon.
Good luck with Stateless. I hope to hear how you've been progressing with it.
For Workflow Foundation, only use it for green project so you can use WF4. Check this out
http://realworldsa.dotnetdevelopersjournal.com/goodbyewindowsworkflowfoundationseeyouin2011.htm
WF 1.0 and 1.5 are not compatible with WF4. So it's not a forward solution.
I personally use http://simplestatemachine.codeplex.com as an alternative to WF. I have used it in one full production system (asp.net based) to handle a pretty complex business license issuance system (handling 350+ different government business licenses).
I haven't tried stateless yet but it looks promising.
Late to the party. We've used Stateless in production now for over a year and a half, no issues. It is a very elegant solution for processing workflows and you quickly integrate the states with your data model. We represent our states with and int in SQL, so you can run the state machine in ASP.Net in process. This is true for long running workflows as well.
If your requirements are basic, a very simple StateMachine I wrote may be of interest.
Please be warned that it does not (at the time of writing) support hierarchical states.
You can find it on NuGet:
nuget install nstate
or check it out on GitHub:
https://github.com/benaston/NState
I hope someone finds it useful.
If you haven't looked at the Windows Workflow Foundation it's probably at least worth doing a bit of reading about it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have some 5+ years' background in C++/Unix development. I have been trying my hand at C#/.Net/WPF based software development for some time now. I am at a stage where I can write functioning applications fluently, but am not sure how to take my skills to the next level.
So, my question(s) to you all, especially to those who are experienced in C#/.Net/WPF:
What are the component skills and knowledge that an expert developer on this platform should have?
What technology-specific books would you expect a would-be expert to have read?
What other deliberate steps can I take to become really good at application development using C#/.Net/WPF?
Many thanks in advance! I would be especially grateful for comprehensive answers - I'm pretty sure many other developers have similar questions.
Learn how the C# language and .NET runtime work by reading CLR via C#.
Scott Hanselman's article, "What Great .NET Developers Ought To Know", is a great resource on the subject.
My team has worked in C# for the past 5 years. Typically, experienced C++ programmers take a week or two to become fully functional in C#. I've even seen some do it almost instantly, after sitting with them one morning, showing them our code, and explaning the basics of the language that differ from C++. But that's not how I recommend you do it.
I recommend you do this:
Read a C# book: My pick would be Programming C# by Jesse Liberty. Important chapters are the language itself and the basics of the .NET framework libraries. The .NET Framework is huge, so you don't have to know everything in detail. You can skip through (or skim) the Windows Forms chapters. Windows Forms is so different from WPF that it won't be useful to you if you are planning on only doing WPF.
(source: amazon.com)
Read a WPF book: The best book I read so far is Windows Presentation Foundation Unleashed by Adam Nathan. WPF has a steep learning curve compared to Windows Forms, even for experienced C#/WinForms programmers. It has a lot of complex elements to understand like XAML, dependency properties, bindings, templates, animation, resources, etc. This book teaches you the basics gradually and is easy to read and understand. And it's in full color!
Read about the Model-View-ViewModel pattern: I haven't found a good book on that yet, but it's been very important for me to make my WPF applications more simple and manageable. My favorite material to learn about MVVM is this one hour presentation by Jason Dolinger. He builds a WPF application from scratch using no particular pattern, and step by step, migrates it to the MVVM pattern.
Also have a look at this past Stackoverflow question: Questions every .NET developer should be able to answer.
For WPF specifically (and the power of WPF binding) I like M-V-VM: http://karlshifflett.wordpress.com/
Make sure you learn how to use and leverage Dependency Injection / Inversion of Control in your applications. Other very important pieces of software to learn to include with your development is Microsoft Enterprise Library and Windows Communication Foundation. Those 2 tools offer an amazing amount of leverage to avoid having to recreate the wheel to solve problems.
Other really good packages to become familiar with are NHibernate and Fluent NHibernate.
Windows Workflow Foundation is a very powerful piece of software however the complexity level is high this would be another great addition to your knowledge base time permitting.
I would add unit testing, TDD, and mocking frameworks to your list of things to know.
I have "The Art of Unit Testing" and found it helpful.
I really like WPF in Action and Programming .NET Components is essential reading for any .NET developer.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What mainstream frameworks, patterns, and tools would you choose to develop two projects in parallel, one in C#, one in Java, in order to minimize the total effort. (Disregard the obvious cases of interchangeable or equivalent tools, like SCC, Unit Testing, etc. Also assume generic broad RDBMS support.)
"Mainstream" means the market in general won't disregard the result because it uses something untested they've never heard of, or arcane skills are required to implement and support it.
Assume a broadly applicable tactical business appication.
db4o uses an in house tool called sharpen to maintain one source repository (Java I think) and convert it automatically to C#.
As they say in thier blog post:
Before you start dreaming: sharpen is not a "magic wand". Don't expect to feed it an arbitrary Java app and receive a running .NET version at the push of a button. The translation process will require some design compromises on the Java side, and parts of the .NET code still have to be hand crafted and integrated into the converted sources.
However it is still quite a cool project. Also, I think it would work best for a new project. Released under the GPL but you have to register with developer.db4o.com to download it.
Edit: Here is an example blog post too.
That's tough. While there are some good libraries available ported to both platforms, when it comes to frameworks, there doesn't seem to be much commonality.
The drift I've gotten here on SO is that there isn't much deviation from the company line in the .NET world. It would be as if everyone in Java used only EJB, JSF, and JNDI, and never came up with Guice, Struts, or Hibernate.
If I could, I'd take a different tack: instead of developing the same system in parallel, develop one system, and put a wrapper around it to support the other platforms. The drawback to this is that the other platforms are doomed to lag behind the primary, e.g. Mono. This drawback also applies to ports of some libraries themselves, like Spring.net or Guice.net.
Or you could invent your own Wasabi.
I've read good things about Mainsoft applications, although I never had to use it myself.
Why would you want to develop for Java and C# in parallel?
You could just use Java and J#. The only problem is, that J# is stuck at Java 1.4 level, so you have two choices:
don't use this fancy stuff like enums, generics, for-each
use a tool like retroweaver to convert 1.5 back to 1.4
I've just finished building a mid-size application (about 80 classes / 30.000 lines) that runs nicely on Java and .NET this way.
As far as I know, the Java Classes compiled by J# are .NET-bytecode that is like any other .NET-bytecode, and can be used in C#. But you don't have to code your core classes twice.
Depending on the scale of the project I would suggest the following technologies and approaches:
Since UI in Java and C# are so different I would build an XML representation of UI for both projects... And then decide on one of two options
a) Static and single generatios of the source of UI classes for both projects on the basis of the common XML (this might be somehow integrated with your building process so that the whole process would ignite automatically)
b) Dynamic generation of UI in both cases (probably harder to realise)
To make the architecture of both project similar I would use Spring and Spring.NET
Also to draw as many similiarities I would decide on NHibernate and Hibernate
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This might be a weird question. After all, most people want to jump OUT of PB not IN.
However, after careful analysis, I feel that Powerbuilder can get things done so much more rapidly than C# in the sense its a 4GL.
Now PB is becoming .NET enabled, I was thinking perhaps its a good tool.
My main focus is developing enterprise applications with alot of data entry/reporting/data representation.
I have tried the datagridview and its pretty bad compared to the datawindow. I initially wanted to buy and try the telerik solutions but due to lack of time, i just assume the implementation in C# is just as unwieldy.
Do you feel its a good idea to jump into Powerbuilder now since its the only 4GL committed to moving to .net?
Thanks so much all. Do not hesitate to critique my choice based on my crieria:
c# is very low level and theres alot of coding to be done concerning data bound controls and so on
powerbuilder is a 4gl and has excellent abstractions to avoid unneccessary coding. Sure, you give up a bit of control but how much control is required for an enterprise application? C# is an extremely powerful language and yes you can make literally anything in C#. But Powerbuilder is more limited, and more can be done in PB when making stuff in its scope: i.e. enterprise apps
powerbuilder is moving to .NET and it can be extended by using C# for more sophisticated stuff.
yes, i am aware theres a DataWindow.NET control which is excellent but however does not give assurances of longevity since Sybase may not continue supporting it after traction for PB.NET is seen. After all it will cannibalize sales for PB.NET
You are correct that PB can be very productive. And ultimately, the strategy of "using what works" is fine. That said, there are some things to be careful about.
It sounds like you are developing a brand new app. If so, that's good, you have a chance to build it as a .Net PB app from day 1. PB 12 is to C# what PB classic is to C++, so your reason (wanting a higher level entry point to .Net) to use PB is in line with what I think Sybase was intending.
Do it as part of an overall solution including the .Net integration you speak of, and definitely take advantage of the educational opportunity to learn C#. As a developer, .Net is better for future opportunities than PB.
Will you need to readily hire additional resources to help develop/support the application? It may be harder to find PB resources than .Net resources, given the language popularity trends. Note that I make no claims on the quality of the developers: PB or .Net, you'll find journeymen, hacks and stalwarts in both ranks.
I wouldn't worry too much about Datawindow .Net if you decide to use it. I don't expect it will go away but someone more familiar with it may be able to provide more context here.
Finally, although there is some value in having a higher level entry point to C#, you will have to learn something about both PB and C#. Managing two tools introduces more overhead than managing one tool. For typical CRUD apps where you are building a lot of data entry and reporting, the productivity gains and strong relationship between SQL and the datawindow may be worth it - that's up to you to decide.
If possible, I would suggest you wait some time to see how PB12 is really doing. What worries me is this:
Existing PB application can, theoretically, be compiled into native code. This works horribly. Or, to be precise, it doesn't work at all. How well is PB going to export to .NET is yet to be determined. They seem to be committed to that, but I wouldn't trust them without seeing some real-world proof that works.
Based on PB11.5 and below, Sybase has been doing a bad job with PB IMHO. They rush into new technologies, but the foundations are shaky. PB12 is a big change, and based on their quality of development, I would wait at least a few builds before using it.
PB can indeed be productive, but being a PB programmer, I just can't imagine someone actually getting into it now. You'll have a very small community, not much open source, and an unclear future. And, based on recent experience, Sybase's support is also quite lousy.
Finally, if you do go through with this, the best advice I can give you is this: design your project having in mind you might have to port it to another language one day. Can't say exactly how since I'm not a .NET programmer and I haven't used PB12 yet, but have that in mind. I wish our app, which goes back up to PB3 or even PB2, was portable.
thanks so much everyone.
I have decided to stick with C# due to a fear (perhaps irrational) that Sybase will be slow to catch up with future .NET upgrades
Because I am still young and working on greenfield applications, i prefer to choose a language that has longevity and support.
Nevertheless, I feel its a shame that Powerbuilder isnt as popular compared to other language, for I can see awesome producivity improvements and the datawindow control is one of the more impressive databound controls i have seen in a long while.
Thanks again, eran and Bernard!
I don't think you have to fear that PB will go away anytime soon, it has been around a long time ever evolving and it will continue to stick around. There is a very active user community and many larger corporations still use it.
I think also it is good to learn as many tools/languages as possible at least from perspective of coming in contact with different programming paradigms. PB is great for certain projects, C# for others - they don't necessarily cancel out each other.
You can take a look at the latest PB.NET (Beta2) here