My friend said he was going to create an application inside of Excel. I told him that maybe he meant macros but he seemed convinced he could create a typical CRUD application INSIDE of Excel.
Is this true?
You're both right. You can use VBA inside Excel and some form functionality to create a fully functional CRUD process with a UI inside of Excel, and you could persist that data to your workbook or to some other storage area (text, XML, Access, another DBMS). It would not be a full application, per se, as it is limited to running inside of the Excel app, but it would be something more than a simple macro of "do these pre-defined steps in order."
Sure. Why would you want to?
The short answer is that using VBA, you can create background worker methods that can interface with other Office apps, or with .NET/COM code. However, if you want to add complex business logic to an Excel presentation layer, my first thought would be to create the application in C#, and use the .NET Framework wrappers for Office interop. The first advantage is that you use Excel SOLELY for presentation, supporting an MVC-ish software design. Second, you keep the code where you expect to find it; in code, not embedded in a document.
You might use Excel/VBA because:
You have VBA--a fully-loaded programming language (though the OO needs work).
Scalar functions are overloaded to work with arrays.
A decent IDE and debug facility.
Excel provides a rich event-driven platform and extends VBA's capabilities with spreadsheet behaviour that "just happens" but would take a lot of coding in a conventional language.
Form widgets that you can put anywhere, not just on a form.
Simple but adequate vector graphics.
Charts, charts and more charts--all dynamic.
Automatic persistence or, if it's called for, interfaces to just about every file and database medium, including XML and cloud services.
Relational tables are a native structure.
If it weren't past midnight, I'm sure I could think of some more good reasons, but hey....
Sure you can.... use VBA and populate cells with data from a DB, when the cells change values update the database
But why would you is the bigger question here
It is true. VBA can summon COM, which can do pretty powerful things. I used an excel file for receiving reports built by a macro inside, that searches many remote databases to group and aggregate information. You can modify the registry, make it run programs, make it restart the PC, show messages, create and edit files, make it use Word or Access, call .NET functionality. Anything that doesn't require complex rendering of something.
Related
A client wants to "Web-enable" a spreadsheet calculation -- the user to specify the values of certain cells, then show them the resulting values in other cells.
(They do NOT want to show the user a "spreadsheet-like" interface. This is not a UI question.)
They have a huge spreadsheet with lots of calculations over many, many sheets. But, in the end, only two things matter -- (1) you put numbers in a couple cells on one sheet, and (2) you get corresponding numbers off a couple cells in another sheet. The rest of it is a black box.
I want to present a UI to the user to enter the numbers they want, then I'd like to programatically open the Excel file, set the numbers, tell it to re-calc, and read the result out.
Is this possible/advisable? Is there a commercial component that makes this easier? Are their pitfalls I'm not considering?
(I know I can use Office Automation to do this, but I know it's not recommended to do that server-side, since it tries to run in the context of a user, etc.)
A lot of people are saying I need to recreate the formulas in code. However, this would be staggeringly complex.
It is possible, but not advisable (and officially unsupported).
You can interact with Excel through COM or the .NET Primary Interop Assemblies, but this is meant to be a client-side process.
On the server side, no display or desktop is available and any unexpected dialog boxes (for example) will make your web app hang – your app will behave flaky.
Also, attaching an Excel process to each request isn't exactly a low-resource approach.
Working out the black box and re-implementing it in a proper programming language is clearly the better (as in "more reliable and faster") option.
Related reading: KB257757: Considerations for server-side Automation of Office
You definitely don't want to be using interop on the server side, it's bad enough using it as a kludge on the client side.
I can see two options:
Figure out the spreadsheet logic. This may benefit you in the long term by making the business logic a known quantity, and in the short term you may find that there are actually bugs in the spreadsheet (I have encountered tons of monster spreadsheets used for years that turn out to have simple bugs in them - everyone just assumed the answers must be right)
Evaluate SpreadSheetGear.NET, which is basically a replacement for interop that does it all without Excel (it replicates a huge chunk of Excel's non-visual logic and IO in .NET)
Although this is certainly possible using ASP.NET, it's very inadvisable. It's un-scalable and prone to concurrency errors.
Your best bet is to analyze the spreadsheet calculations and duplicate them. Now, granted, your business is not going to like the time it takes to do this, but it will (presumably) give them a more usable system.
Alternatively, you can simply serve up the spreadsheet to users from your website, in which case you do almost nothing.
Edit: If your stakeholders really insist on using Excel server-side, I suggest you take a good hard look at Excel Services as #John Saunders suggests. It may not get you everything you want, but it'll get you quite a bit, and should solve some of the issues you'll end up with trying to do it server-side with ASP.NET.
That's not to say that it's a panacea; your mileage will certainly vary. And Sharepoint isn't exactly cheap to buy or maintain. In fact, short-term costs could easily be dwarfed by long-term costs if you go the Sharepoint route--but it might the best option to fit a requirement.
I still suggest you push back in favor of coding all of your logic in a separate .NET module. That way you can use it both server-side and client-side. Excel can easily pass calculations to a COM object, and you can very easily publish your .NET library as COM objects. In the end, you'd have a much more maintainable and usable architecture.
Neglecting the discussion whether it makes sense to manipulate an excel sheet on the server-side, one way to perform this would probably look like adopting the
Microsoft.Office.Interop.Excel.dll
Using this library, you can tell Excel to open a Spreadsheet, change and read the contents from .NET. I have used the library in a WinForm application, and I guess that it can also be used from ASP.NET.
Still, consider the concurrency problems already mentioned... However, if the sheet is accessed unfrequently, why not...
The simplest way to do this might be to:
Upload the Excel workbook to Google Docs -- this is very clean, in my experience
Use the Google Spreadsheets Data API to update the data and return the numbers.
Here's a link to get you started on this, if you want to go that direction:
http://code.google.com/apis/spreadsheets/overview.html
Let me be more adamant than others have been: do not use Excel server-side. It is intended to be used as a desktop application, meaning it is not intended to be used from random different threads, possibly multiple threads at a time. You're better off writing your own spreadsheet than trying to use Excel (or any other Office desktop product) form a server.
This is one of the reasons that Excel Services exists. A quick search on MSDN turned up this link: http://blogs.msdn.com/excel/archive/category/11361.aspx. That's a category list, so contains a list of blog posts on the subject. See also Microsoft.Office.Excel.Server.WebServices Namespace.
It sounds like you're talking that the user has the spreadsheet open on their local system, and you want a web site to manipulate that local spreadsheet?
If that's the case, you can't really do that. Even Office automation won't help, unless you want to require them to upload the sheet to the server and download a new altered version.
What you can do is create a web service to do the calculations and add some vba or vsto code to the Excel sheet to talk to that service.
I hope it may be a advanced concept in .Net
My question is
How to setup a program with optional reference?
For example: Consider this case,
I've certain program which is capable exporting data to Excel.
This feature needs reference to Microsoft Office Excel (Some specific version)
Is there any way to write a program which run whether or not Excel installed, but some particular option (like reading or writing Excel) will be done only if Excel installed.
Program should run even when Excel is not installed.
Thanks.
There are two basic approaches.
Assembly.Load allows you to load arbitrary assemblies are runtime, inspect their contents, instantiate objects, call methods and so on. You would normally hide that behind things like an interface, a default implementation, a factory method and so on. Dependency Injection may rely on techniques like this.
You can use the Microsoft Managed Extensibility Framework, which does all this and more. See http://msdn.microsoft.com/en-AU/library/dd460648%28v=vs.110%29.aspx.
Excel is a bit of a special case, because it's accessible through COM automation, which provides some other opportunities and can add some other complications. You can usually build and run the program because the wrapper assemblies will be present, and handle execution failures at run-time if Excel is not.
Whichever way you go there can be quite a bit of code to write. There is not enough detail in the question to say much more, but it's not just a matter of setting an 'optional' flag.
I'm looking for input on a direction to take for building an accounting application. The application needs to allow for high customization, sometimes entire processes will need to changed.
I want a way to make changes without re-compiling the entire application when a customer has a specific modification request. The back-end will be a SQL database of some sort. Most likely SQL Server Express for cost reasons. The front-end will be C#.
I'm thinking of an event-based system that will have events for when different types of actions, such as entries, are made. I would then have a plugin system that handles the event. I may need to have multiple processes apply in a specific order to the data before it is finally saved. It will need to trigger other processes as well.
I want to keep my base application the same, which works for most customers, but have a graceful way of loading the custom processes that other specific customers have.
I'm open to all suggestions. Even if they are thinking of completely different ways of approaching the problem. Our current in-house development talent is .NET and MS SQL Server. I'm not aware of a software pattern that may fit this situation.
Additional Info:
This isn't a completely blank slate system, it will have functionality that works for a large number of the customers. For various reasons, requirements change based on states and even at the region and town level where customization may be necessary.
I'd like to be able to plugin additional pre-compiled modules. When I started looking into possible options, I was imagining an empty handler that I could insert code into through a plugin. So say for example, a new entry is made to the general ledger that raises an event. The handler is called, but the handler's code is coming from a plugin, which may be my original process that fits 80% of the customers. If a customer wants a custom operation, I could add a plugin that completely replaces the original one or have it add an additional post processing step through another plugin after the original runs. Sort of a layering process I guess.
You could look at Managed Extensibility Framework
It provide rich composition layer features that allow you to build loosely-coupled plugin applications.
Update : sound like you need the pre-defined modules on different geographic areas and using chain of responsibility design patern might help you manage the principle of change.
Sorry no codes provided just throwing my thoughts
Windows Workflow Foundation (WF) (part of the .NET Framework) is a potential candidate for your requirements. It enables various actions, command-lets and script-lets to be composed dynamically so that you can more easily customize different workflows for different users/customers.
WF is used by Biztalk for large-scale systems integration and is hosted in-process by many other applications that require the ability to easily modify the orchestration of a number of smaller tasks and actions.
You might want to start with this tutorial on WF4.
HTH.
It's not just plugins or the way how do you technically resolve that plugin problem, use MEF (+1 #laptop) or something else, You got to put most effort in defining plugin "points" in your application, this is gone be most important eg. where you will put that empty "events" to put your code, or what parameters this events or plugins will have.
For example usable plugin would be in before save event, but you will have to have only one place in application that will save various types of business documents, so you can call plugins there and parameter would be abstract document object.
So you have to think real hard about your system architecture, to be abstract enough for various plugin points, and do that architecture completely, don't do just a part of the system and start coding on that.
I hope that you understood what I meant to say, because English is not my native language.
Okay, I'm biting the bullet and deciding to get into the whole Microsoft/C#/.NET culture and I'm going to do this by putting together a simple (hah!) application.
It will basically be an application in which I want to store images and associate with them other optional things.
It must be able to import images from the filesystem (and hopefully camera/scanner) then allow the user to add text, audio and other information.
I plan to store the images and auxillary information into a database. What the application will do with said data isn't important (yet).
Keep in mind I know absolutely nothing about C# or .NET although, as an old codger, I know a great deal about many other things and will regale/bore you with stories and anecdotes until you quietly slip away :-)
What are the first steps to take in developing such an application? I've already set out UI layouts and likely process flows although it may be that the development environment dictates changes.
Development environment is currently XP SP3 + VS2008 (though I can upgrade if absolutely necessary).
What should I be looking at as the first step? Are there any gotchas I should be looking out for?
Have you decided for win forms or WPF? I've been doing win forms for the past 4 years and WPF was a great discovery for me, with the flexibility it affords. It might be fitted for your application and the different types of content you'll want to add and give you a flexibility that win forms can't give.
As for actually developing, I think loading images from the disk would be the first step, showing them in the UI and getting user input for them - you would get to work with the different objects and see how the framework handles things.
A tutorial about the field validation I mentioned in my comment is here - haven't done it, but something similar. You can also see the xaml code paired with the C# code there.
After looking for the differences between win forms and WPF I found that there are a few win forms controls that are missing from WPF. More on that on MSDN (compariosn chart) and a post from March with a more detailed chart.
It's also worth mentioning that you can include win forms controls in WPF applications and vice versa, but there are some limitations.
Just a couple of pointers, it would be easy to overwhelm you as you are just starting with this tech stack. First step, use SQLServer 2008 Express, it has better ability to deal with image data (images can be saved directly to the filesystem, but they are still in a table).
Apart from that, you can design your screen with the GUI, and then hook the bits up one by one to your retreived data. Create a new Windows Forms app, or a WPF one, and start from there (i'm assuming that you know about the toolbox window and just dragging components on to the designer and setting their properties in the Properties window).
If you're looking win forms you're going to have drag-and-drop UI pretty easily.
If you want to use a database than you're probably going to find MS-SQL the easiest to cooperate with. Look up LINQ-2-SQL, it lets you access your database through an object layer by simply dragging your tables onto a pane.
Fun things to use: extension methods, partial classes, LINQ (query any collection with inline lambdas) and even class/method attributes.
My $0,02:
a) Get to know the platform a bit, types, collections, events/delegates(/lambdas), etc etc
b) Dive into WPF
c) Learn about database connectivity (LINQ2SQL or NHibernate (or ....)
d) Learn about the MVVM pattern to get to deliver solid wpf applications, doing so forces you to dive deeper into the workings of WPF (routed commands, tunneling/bubbleing etc)
e) Learn more about patterns to get a more solid grasp of OO (this: http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1276066663&sr=8-1 is an absolute pearl for that)
f) etc
If you aren't too desperate to get your hands dirty straight away I'd suggest this book: CLR via C#.
It is written for those with programming experience on platforms other than .Net and provides a clear and comprehensive explanation of C# and how it runs on the .NET CLR.
By reading this initially you might avoid writing some of the poorly constructed applications that many of us wrote before properly understanding the technology.
Buy a book on C# & .NET FW fundamentals!
Read! :-)
Read good books about .NET for example CLR via C#.
Read this:
Hidden Features of C#? https://stackoverflow.com/questions/380819/common-programming-mistakes-for-net-developers-to-avoid
I have been handed a critical macro that takes an old school file full of invoices which thankfully is quite consistent. The macro reads this file, moves the data around to make it consistant and then generates a three tab speadsheet which is pretty much three CSV's. It then generates off these three CSV's another speadsheet which has a tab for each invoice. The amount of invoices can really vary.
It works, everyone is happy. We would like to put this out on the web with some security. For now, have it so that the user:
1) Logs in, uploads the old school file and presses process which will then spit out the same speadsheet with each tab being an invoice.
2) Store the data in a database for future growth and use of this data, as well as reporting.
I'm teaching myself ASP.NET and C# and think this would be a great learning project. Before I jump into it, can this realistically be done and what would others recommend in this case? Should I simply re-write based off the logic in the macro or is there a way to port over existing VBA code?
You can do it with an Excel COM API. But this tends to lead to memory leaks, I would not recomend it.
Microsoft has Excel Services which allow you to run Excel Spreadsheets on the server. But it is very expensive and may not support Macros.
SpreadSheetGear may be able to do it. But I have not tested it myself.
I would recommend that you rewrite the application in C#, you would get a better solution, and it may not take you any longer than getting the spreadsheet running on the server.
Using the Excel COM API from a web application is difficult. There are security issues which are non-trivial to address. If you wanted to retain the excel processing then you could build some sort of an out of band process which monitors an upload directory and, when it detects a new file, kicks off a process of transforming the excel file as the old macro use to.
There is no easy transition from VBA to C# since all the VBA code assume the existence of excel which may not be the case. However you can call macros in workbooks using the COM API.
Driving Excel from C# is surprisingly hard to get 100% right. Conversely, driving Excel from a VB6 application is surprisingly easy. But, calling this from a web application makes it harder, since you need to deal both with security and concurrency (2 users at once will trip over each other).
Microsoft don't support the use of Excel on the server (apart from Excel Services), so don't expect any help there. SpreadsheetGear is suited to this, but you'd have to pay for it.
You say this would make a good learning project - I'd disagree; it's likely to put you off programming altogether. This particular mix doesn't have a "nice" solution - it's a case of finding the least-unpleasant hack. If you want to learn ASP.NET & C#, I'd say find another pet project.