Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I have an Excel application with one entry page and one result page. Based on the data entered into the entry page and some static tables present, there are some other worksheets which calculate the values and sum it up later in the results page.
I need to convert this application to a web application and move the whole logic from excel to C#. There will be some UI pages and 1 results page, and the worksheet calculations currently in the excel application will be moved to different C# classes.
Is there any tool for this, or do we have to manually convert every piece of the existing logic to C#? If we have to do it manually, then is there any tool which can help summarize the logic in a text file, so that we don't have to backtrack the whole calculation in Excel to reconstruct the logic?
I doubt a tool could help you do this, and if that tool existed I would expect the resulting C# code to be pretty bad. One of the forces of Excel is that it permits a very flexible programming style; the downside is that the resulting code has very little structure to it, which makes it hard to follow, both for humans and machines. On top of that, the logic can take multiple forms, from an Excel formula to a VBA macro, which complicates matters.
By contrast, C# tends to see the world in terms of classes, which have very specific responsibilities; a program essentially coordinates passing messages between classes so that they can "talk to each other" and collaborate to get the job done.
In that context, at best, I would expect a translation tool to produce a few unpleasant C# procedures. In the end, a spreadsheet (with no VBA) is a set of functions sitting in cells and chained together, there isn't enough structure present to extract meaningful classes/entities that own pieces of functionality.
Furthermore, I would argue that re-thinking this application is an opportunity. A web app can do easily things Excel can't, and vice-versa. Instead of a "word-for-word" close translation, I would focus on retaining the spirit of the application, but design it without thinking too much about the original Excel application.
The benefit of having the Excel application present is that you have a proof of concept already. Instead of trying to convert the code, I would simply track down all the input points that have an influence on other calculated fields (maybe using auditing), list / diagram what influences what (maybe with a simple bubbles- and-arrows diagrams), and attempt to describe in plain English what the user is attempting to do, and what is happening in terms of "entities". For instance, rather than =A2*(1-A3), I would say "the Product Net Cost is its Cost time (1 - Discount Rate)". And instead of =SUM(A5:A32), I would say "the User wants a summary of the cost of the Products he ordered, which should display the Total Cost of his Order, so that he can have an overview of his order". If you manage to extract a description of your domain with good names and use cases, this will be more helpful to a developer to write the best possible application supporting these requirements, on any platform you may want.
I wouldn't try to "convert" the solution. Build it in C# from scratch. They are written in different languages and the UI cannot be reused.
I agree with fabiopagoti. Even if a magical 'converter' would be available, what human would dare to maintain this coded-by-machine application in future updates?
Taking your second question, looking for an alternative helper, I've found the [CTRL]+[`] key combination that may give you a hand on this: This shortcut displays all formulas in cells, so you can be more confortable you're not missing anything behind. I hope.
PS: To text file? Just apply the shortcut and "print" the sheet to a PDF file.
May be you can use Google Docs. It allow to create scripts and use formulas.
Related
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 5 months ago.
Improve this question
I am developing a light weight web app in ASP.NET with C# and I would like to store some data such as site analytics etc.
Instead of using a SQL server database could I use a JSON file instead? So I would open the JSON file and write into it when done. Could there be problems with simultaneous connection?
Is this standard/ common practice?
Any help will be highly appreciated.
It is probably a VERY bad idea. I would only do this if it was some text file to display a wee bit of information.
If you need updating? Then what happens if two users are on the site. The last person to update will over write the text based json file.
I suppose you could write out a "id" and json file for each record you edit, and that way a save of one record value would not over write others. But, putting more then one reocrd in a json file, and if users are to edit such values, then no, it will not work, since a simple save of that text json file will overwrite any other changes made by any other user who also happens to hit the same button.
It is VERY hard to find a web site hosting, even those for super cheap - less then $10 per month that does not include a database server system. And be it MySQL, SQL server, postgres sql and more? They all have free verisons you can use.
And I suppose you could consider the file based sqlLite. That would even be better. While it not considered thread safe, it can work if you only say have a a few users like 2-4 users working at the same time.
Because you have OH SO MANY choices here? The only reason to use a text based json file is if no other options exist - and boatloads of options exist in near all cases.
And if some database was not available? The I would simple include sqlLite in the project and use that.
I'm not super experienced but i would like to explain why i would never do that.
First of all everything (if you are brave enough) can be a database, as long as it is some kind of file that can give persistency to your data. Database are basically optimized one purpose software to store data. Mainly the problem in your solution is that you would need to read the file and load it in memory storing it as an object and then writing data to it like you would do with a static factory object and then serialise it back to JSON after you are don with it. Personally i don't like this idea because i think is very prone to human error (like deleting the file by accident during mantainance) and it can be hard-er to debug if it starts accumulating a sizeable chunk of data. There are very lightweight data persistency solutions that implements SQLite that is a database for small applications, like Pocket Base. Since you are already developing a backend it would require you near to no effort to add a little table to store the analytics.
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 9 years ago.
Improve this question
I am looking for honest / constructive feedback.
I hear a lot of my peers who have been using .NET for a while now, say how easily they built their GUI interfaces. On closer inspection they have used 3rd party tools such as Infragistics.
As a new .NET programmer (certified I may add), I wanted to know if anyone has actually created interfaces using nothing but what ever happens to be available by default with the framework...
I am guessing it shouldn't be too difficult to create a good, aethestic looking GUI without using 3rd party addons.
Yes We've done it (windows).
Depends on where you put the emphasis in your guess. No its not TOO difficult, but it's definitely not easy, unless your requirements are truly trivial, as opposed to apparently trivial.
All depends on what you need / want to do. My advice don't tell your boss, this will be easy, well not unless you want help getting out of the door for the last time.
For instance take a straight textbox.
They want to enter currency in it.
Multiple rounding algorithms.
Enter raw value display formatted, Currency symbol, thousand
separators.
Optional pounds or pence.
Optional blank or zero
Optional treatment of negatives.
Optional display formatting of negatives.
Alignment on decimal point.
Auto change of font on resizing.
And break none of the standard behaviours.
Trust me not simple at all. Especially if you do something Infragistics did not, and go for a good developer interface as well as the end user behaviours.
Not trying to put you off. It's challenging and rewarding, but when you have the entire application stuck behind some irritating bug in the UI, bosses lose patience real quick and you haven't got that get out of jail free card in shrugging and saying that's how X works.
NB just buying a suite won't fix all these problems, you can spend a lot of time producing a totally crap UI with them as well, just you don't have to write the code...
The answer to that is a lot of hard work. :(
Can your current suite be upgraded?
If you have the source could it be fixed, if you had the source and it's been twiddled with, are those "improvements" interfering?
Needs some hard-headed realistic analysis this. Which components are broke? How much are they used? How much of the extra behaviour in the suite do you really need.
Most important, how good is your separation of concerns in the current code, and how comprehensive both unit tests and automation tests.
Would compatibility mode sort it out?
Need to get to a point where the number of questions doesn't significantly out weigh the number of answers.
I've been where you are though it was another suite in another environment. The people looking for the cheap, quick and painless way of dealing with a mess like this were hugely disappointed, but it can be attacked in parts as long as everybody takes a heavy dose of pragmatism.
As a for instance,
Someone had bought a windows component that looked like a html link, and was heavily dependent on File associations and API calls. It was very visible and all over the place, I knocked up a much better and far less fragile one in a few days, swapped it in, a lot of perceived problems disappeared, confidence increased, and the remaining problems started to look less horrible.
Think of it like going into triage mode on bugs at the end of a struggling release.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 months ago.
Improve this question
Which is the best 3rd party library to use for exporting data and generating charts in the Excel from Asp.net. I have researched on .Net and found the following:
1. EPPlus: Since we are to work in a very tight schedule and the project is also not too long, so we will not be having much time to resolve issues if we get stuck somewhere after using the component. Since that is an open source library, so the time guarantee to get a help to get the issue resolved cannot be there.
2. Spreadsheetgear2012: This seems to be a good library and its site seems to show a good amount of charting examples.
3. Aspose.Cells: This also seems to be a good library and its site seems to show good charting examples although its a bit pricey, but their support seems really good and they seem very open to new ideas from clients to implement in their product and release a new version.
We are not able to take a final call whether to go for Spreadsheetgear2012 for .Net or Aspose.Cells. Any details and ideas will be highly appreciated.
The comparisons that I was able to find on internet for these products were pretty old (around 4 years back).
Our main application is online interaction and reporting from a spreadhseet, rather than generation and downloading of other spreadsheet files. We tried quite a few spreadsheet deployment options and in the end went with Spreadsheetgear. We found it to be very simple to set up, fast and flexible for this purpose. Their online examples and support are also very good.
We have moved on from their examples and have been able to set up their API with an MVC3 ASP.NET framework. It is quite a task to get it working but in the end MVC makes for a very neat code structure and much faster deployment of applications. The combination is highly recommended.
What is the most important to you? Cost, long term plan or support?
The first one is free so if cost is your biggest constraint, you really don't have options.
The second one is cheaper than your last one but it seems to have a smaller user community.
So if you run into trouble, where do you find help?
The third one provides a full series of other related products too. If you think you may need other products later, then you can bundle your existing license and that can save you money.
I am using the third one at work and think it's a good product. They have large user community and their support is responsive. But it does come with a hearty cost.
You are missing another player in this space that, while not as spiffy or as speedy to plug-and-play as the paid options, could perhaps be enough to get you where you need to go with your spreadsheets: NPOI. Even if you don't use it for your current project, it still could be worth looking into as a tool to use at a later point.
CodePlex
http://npoi.codeplex.com/
Scott Mitchell on NPOI
http://scottonwriting.net/sowblog/archive/2011/06/08/export-an-ado-net-datatable-to-excel-using-npoi.aspx
Leniel Macaferi on NPOI
http://www.leniel.net/2009/10/npoi-with-excel-table-and-dynamic-chart.html#sthash.VZ4NjvZK.dpbs
Zach Hunter on NPOI
http://www.zachhunter.com/2010/06/improved-npoi-exportdatatabletoexcel-function/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I've a requirement to be able to generate PDF's within our (ASP.net) application. We need to meet the following requirements:
The text will be largely dynamic and must be added programatically.
Ideally we'd like to base these generated documents off PDF templates provided by our designers.
Some of the sections/pages may or may not be visible depending on certain conditions - ideally we'd like the content to 'flow' upwards to fill the space when something is removed.
Some of the pages may need to repeat, depending on certain conditions.
Some of the PDF templates will be out of our control (we're populating application forms supplied by third parties), so being able to read in a blank PDF and populate it would be good.
I've looked at iTextSharp and it seems to do most of these things (i.e. I can take a PDF, edit it to include form fields where we need to fill data and then use iTextSharp to read that in as a template and populate the data), however, I'm not sure how then to go about potentially hiding whole sections and/or repeating pages.
What I'm looking for here is a little advice from anybody who's been in a similar situation.
Small update here, we went with iTextSharp - it's a powerful tool, but does take a bit of learning, however it's quick, light, and does precisely what we want it to do.
However...
I would point out that the latest version is no longer really free (as in beer) - the license does not permit commercial usage. As a result, we now have a licensed version, but it's not shockingly cheap (and they don't publish a price list).
I would use iTextSharp. I create all kinds of PDF files based on different templates and iText has worked the best for me. It is a very powerful control and can manipulate pdf files in just about any way.
I'm not sure that iText can handle your third requirement. I know that it can create a pdf from a html file. Maybe use what Tomas posted and create the pdf with iText.
There are various commercial components to do this. Look at: PDFLib (http://www.pdflib.com/), Tall Components (http://www.tallcomponents.com/) etc
I have use products from Tall components and can recommend them.
Some others are a lot more expensive.
ITextSharp as you've mentioned is quite good and can be used to add/remove external pages, in this can you could hide full pages by ommiting them, or replacing them with placeholder pages. iText can use existing PDF files or create blank pages.
From my personal experience, I have just dropped in images and text onto existing pages and added pages generated by a reporting tool when tabular data is required.
HTH
Why need the template files in the pdf format? With the dynamic that you want it is a bad format for reporting template. Use a reporting software that also output as pdf. Your designers can create the templates very easy with a GUI. You will find many reporting solutions here on stackoverflow.
We've used http://www.dynamicpdf.com/, for projects like this and have been pleased with the outcome. They have a PDF WYSIWYG designer tool that you can use to build out the layout template of your PDF, along with the tool to merge the template with your data based on field to column mapping. This saves hours of hand coding each element of a given PDF. It supports page headers and footers and deals with the complexities of page breaks.
I would consider using creating HTML files from templates and turn them into PDF with Prince. Prince is very flexible and crating HTML files from templates is much easier then creating PDF files directly.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed last month.
Improve this question
I used LaTeX for writing couple of white papers while I was in grad school. From that I have a really good impression about it in terms of what LaTeX allows user to do, especially the fine control it provides over formatting, etc.
Now I am debating whether I should actually use LaTeX for our production apps to generate PDFs. I have tried several commercial and free PDF libraries (PDFSharp/MigraDoc, iTextSharp, Expert PDF, etc) and none of them provide the amount of fine control I need without making the code base extremely difficult to maintain in long run.
If I do decide to go this route it will be done from C#. Since LaTeX already has command line interface, I should be able to do that pretty easily from C# as an external process forked from my program.
But I was looking for some comments from the community.
Has anyone tried it? If so, what were some gotchas?
What do you think about the idea -- pros and cons (I am more interested in gotachas)?
All feedback is welcome.
I have previously built a platform for report generation that uses plain TeX (specifically the MiKTeX implementation) to generate reports in PDF format. The platform is used to generate approximately fifty reports per month of varying nature (containing mostly dynamically generated tables and charts). The system is quite flexible. Reports are defined via XML (on an internally-defined report description schema). The platform allows the user to specify a source database table, which fields to extract, the formatting of the fields, a mini query language to filter the appropriate data as well as various formatting elements (page orientation, size, titles, and classifications ("Public", "Internal", "Confidential", etc.).
The main "gotcha" is that it takes a ton of work to end up with a code base that is flexible to change and not a total pain to maintain. A second "gotcha" is that knowledge of TeX (outside of academics) is rare so you could end up becoming the de facto maintainer even if that is not part of your usual role.
Pros:
Beautifully formatted reports.
Complete control over layout and look.
Free.
Cons:
Difficult to implement properly.
Difficult to maintain.
Knowledge transition could be burdensome.
Support is effectively non-existant.
I've done a few in-house "production level" documents in LaTeX.
Generating LaTeX documents in Windows is an overall horrible experience, to be honest. I was never able to find any solution besides Cygwin. Once you've got the Cygwin environment up and running, it was as simple as picking out the LaTeX and related libraries from Cygwin's setup.exe.
I haven't tried running LaTeX from a non-Cygwin environment, but in theory you should be able to just run C:\Cygwin\usr\bin\latex.exe -- then there's a chance it will be missing paths since you're not in Bash, in which case you might need to just pass the include directories to subsequent programs.
If you decide to use Docbook instead of LaTeX for your documentation (and I would recommend at least giving it a look, it's much more structured for software-related technical documentaion), I had good experience running dblatex under Cygwin. It's not in the Cygwin repositories, but it's a piece of cake to install from source.
I have done various production PDF implementations using TeX. I ended up abandoning LaTeX, and went with ConTeXt (see also Context Garden).
There is a very active mailing list, it is used extensively for document production, and there is a nice minimal distribution for various Unixes, Windows and Mac OS X. There is no need for Cygwin on Windows (although you do need Ruby).
I find ConTeXt approach to TeX cleaner than LaTeX, but that might just be me.
If you need to publish data summaries and graph, then you can have a look at Sweave. Sweave allows to mix all the functionality of R with TeX. The source code of a report consist of a plain TeX file with some R-code chunk were you need to read, manipulate, tabulate or plot data. Then you 'compile' the Sweave file (from the commandline) which returns a plain TeX file.