This question already has an answer here:
Use Office Interop on ASP.net MVC6 website
(1 answer)
Closed 6 years ago.
I want to generate excel file. That's why I am using Microsoft. Interop. excels library and my work has been done. But right now someone says Microsoft. Interop. excels library is not a good approach for web based projects. It is good for desktop based project. Is it true. If true, so why and what's the issue that approach not suitable for the web. And which is the better approach for generate excel file on web based project.
Actually I have some experience with working with Excel files in both web and windows environments.
My answer to you is that it heavily depends:
Microsoft.Interop.Excel(Let's call it MIE) is cross calling Excel libraries itself to do it's job therefore it's more reliable in case of future versions and better upgradable. But it's not well formatted, there will be no intellisense and most important one you require Excel installed on the running machine.
So base on these info you need to answer these questions:
1- Are you gonna distribute your code or you are going to deploy it?
2- Do you have access to server or no?
3- Is it to create Excel or to read it or both?
4- Is it a project for a long run or a short lifetime one?
1) If you are going to distribute your code find a third party tool. Because if you use MIE you need to tell your customer to install Excel on their machine (which they might be unable to do because of the question 2) and also your code might break because of it's communication issues with MIE.
2) If you don't have access to server (i.e. a hosting deployment environment or your server is managed by your company), you can't install excel on it so let's select a third party tool, compiled in your code.
3) If you want to read excel and you answered the previous questions go for MIE it's a must since most third party tools aren't really good and reliable for opening files. They are mostly able to create ones. Unless you want to create files then you want to use the same files later. Usually third party tools are great in opening files created themselves.
4) If it's gonna work a long time it's better to use MIE because it's essentially better to maintain. Microsoft uses this MIE in their products like Dynamics CRM so they need to keep it backward compatible.
I hope this helps you and it's all based on my own experiences. I'm open to correct myself if I'm wrong so help me in the comments.
Related
Hi i am recently working on a c# window form application. I have done the all stuff and noe it's time to deploy the application, But i am unable to activate the visual studio installshield feature. Can any one here able to tell me any alternet way to create me a setup file of my application. Like Innosetup compiler or other.
Visual Studio Setup Project is easy to work with and is available for both VS2013 and VS2015 in the form of Visual Studio Extension (separately from the default VS installer). Download figures suggest that a whole lot of people are using this extension.
I prefer to use InnoSetup, which is free for any use including commercial.
You can have a UI to make creation simple, but if you want really complex functionality you can write code to create those functions. There is a thriving community of developers that use and contribute to the product, so finding examples is usually easy, but you do have to write your code in Delphi / Pascal.
On the other hand, all the Microsoft options are overly complicated and difficult to get working sensibly so I am pleased to avoid them. Corporate installers are good but incredibly expensive... so really there is no comparison. Ease of use, and free - what more could you ask for?
I should point out that I have absolutely no connection with the product other than that I have used it for many years for many products and have absolutely no complaints.
That depends on your needs.
Mostly you can just create an msi installer with an installer project type on VS.
The problem is that a lot of software distributors require an exe file type. For that you can use the free (limited ) edition of install shield : http://learn.flexerasoftware.com/content/IS-EVAL-InstallShield-Limited-Edition-Visual-Studio
It has everything that a standard installer needs and I use it to distribute my software.
I tried other free msi to exe programs but none of them worked well (this was a while a go and maybe things changed since then)
I'm a hobbyist programmer and I've created an application for my office. Every so often I need to improve the code, add features or fix issues that come up under certain circumstances - I've found bugs or ineffective coding even after 3-4 months of heavy usage of the application. The thing is that whenever I modify the code, visual studio saves the changes. This means that if I want to use the program I'll have to be really fast in coding and debugging or it won't build - and I won't be able to use it...
Is there any way to keep the old version of the program without having to save the complete project folder elsewhere? Like creating a new version but keeping the option to go back to the old - working - one...
What you are looking for is called source control.
There are many systems out there, two popular ones are subversion and Git.
Used properly, you will have a full history of each file you have in your project.
There are two other answers here regarding source control at the time I write this, but there is another angle on this as well.
You're executing your production copy from the development directory. Don't do this.
When you have developed the program to a stable version, make a copy of it somewhere else and use that copy. In this way you're free to keep developing on the software without destroying your ability to keep using the existing stable version.
As for source control, you should definitely use that as well if you're not already doing it. It would, among other things, allow you to go back and hotfix the stable version with minor bugfixes while still doing major rewrites of the software, as well as the features others here have mentioned, full history of your project, "unlimited" undo, etc.
I'm not sure what you mean that Visual Studio saves the code when you modify it. It does by default save when you build, but I don't think it saves while you're typing.
Anyway, what you're looking for is called a source control system.
You can try Team Foundation Service from Microsoft.
It works fine and you can share youre project whit colleagues.
http://tfs.visualstudio.com/
EDIT:
This is a free of charge option you can use, until you want to share youre project with more than 4 persons!! than you have to pay for TFS
You need source control.
If your project is open source you can use codeplex, it's an open-source Website where engineers and computer scientists share projects and ideas. Its features include wiki pages, source control based on Mercurial, Team Foundation Server or Subversion (also powered by TFS), Git,discussion forums, issue tracking, project tagging, RSS support, statistics, and releases
If you don't want to share your code you can use Team Foundation Server
i have a project where i do something i have same copy from another who have do something in it later i have a thing to do currently.
so that's three copy and i am unsure that i am not confused with it. sometime i call wrong copy for finding the thing i want from them.
without using any software outside our office window any trick to manage all project or how i can manage them and make them one copy.
the same problem with some other problem come with when the same script used in two software , website who are used same script with have a small difference in both.
so i want to know how exactly all other manage them. i want to have a answer with .net plateform.
There are several source control solutions that have plugins to integrate directly with Visual Studio. I would recommend looking into Subversion. Currently at my office we use Vault, but it has some short comings, especially when it comes to renaming or moving a file and then editing it prior to a check in.
http://ankhsvn.open.collab.net/
http://www.sourcegear.com/vault/
I recently started a small pet project. It's written in C# with ASP.NET MVC3. As it's grown, my needs for source control also has grown. Here's what I've done:
Day one, I placed my project in a Dropbox folder. That way, I could reach my project files from all my computers (and even my iPhone).
A few weeks later, when I first had to make some serious changes and neede a fallback, I created a Mercurial repository in my Dropbox folder and commited all my code. I've got a blogpost on that here: http://csharptutorial.blogspot.com/2011/06/using-dropbox-with-mercurial.html. Mercurial is a great versioning system, because it doesn't require a server installation and your repository is copied in full to all locations where it's checked out.
Now, I'm looking at moving my project over to BitBucket (http://bitbucket.org/) where you also share and discuss code with others.
A good alternative to Mercurial is Git, using github.com in stead of bitbucket.org. Both have a learning curve, but they both represent modern version control tools and is well worth having a look at.
Source control and discipline.
You need to get an approach and method for managing your source. A source control system is essential for this. I use SVN and Ankh, as does Clayton.
However, you need an approach for using this. I always have branches. You can have development branches and merge these changes into a release branch when your code has passed all the tests. This way takes a discipline and time, but you need to do this to build quality into your system.
We need to have documents shared between clients (CRM-like functionality). Users need to be able to:
Edit the documents and save them again
Attach new documents
Our application is coded in WPF with WCF for data-transport and NHibernate/SQL for data on the server.
what we're thinking is to use SVN and have the app create a local check-out of parts of the repository (when they click a document, it is checked out by SVN in the background and opened from the local path) - When saved it will silently (using monitoring of the path) be committed back to the repository.
Question: Is this feasible - or are there better solutions to this?
EDIT 1:
Summary so far:
I'll look into using Git/Mercurial instead of SVN
Document size (revisions) might be prohibitive pending tests
SharePoint is an option (although not viable in my case as the cost alone is prohibitive) - I will look into the alternatives for SharePoint, tho.
Not much experience out there about using repositories for many users although it works for small teams..
Wiki software might be an alternative to SVN.
Thanks for all the feedback - I'll keep it open a bit longer.
EDIT 2:
Summary after a few days of work - I have a client working - see my progress here.
Based on the heavy .NET references, are you all set up with MSDN? Perhaps you can make use of SharePoint...which may already be included within your MSDN account.
You might also want to consider using a Wiki for document management - I've seen this done and do it myself for my own organisation. We're using Atlassian's Confluence Wiki. Confluence provides for the versioning and general management of documents.
I wouldn't use SVN for this, SVN is not very efficient when dealing with binary files. By using SVN as a back channel for some content in your application you just complicate things by adding another technology and dependency, but you will not use much of its real potential.
I would store the documents as blobs in the database and get/store them through WCF.
Generally I don't think that SVN or any version control system is a good thing to use for sharing documents. Main disadvantage is the diff system on binary files... Your SVN repo will grow rapidly..
Maybe you should try using some of the commercial tools designed for document sharing (eg. Microsoft Sharepoint). Or some Open Source alternatives... Perhaps you should read this post...
It depends on the kind of documents you are using. If you have lots of changing, compressed binary files, then don't use it.
However, if the documents are in an open format like a Wiki language, (X)HTML, LaTeX or uncompressed ODF, then using a version control system makes absolutely sense. Also, a bunch of compressed ODF files or PDF files are handled very well, especially if the files are mostly smaller than 5 MB or so.
In addition, make sure to check some more recent version control systems like Mercurial and Git before sticking to the conceptually outdated SVN. In your scenario, you won't profit much from the "distributed" part of Mercurial and Git, but they are nevertheless easier to setup - at least to my experience. And they provide very advanced version control features which can save your day in the rare cases when you need them.
In case you stick to SVN, and if your client software runs under a modern Unix system, you can also try SVN-FS. This is a filesystem that uses a remote SVN server. Each read goes to the latest revision. Each write creates a new commit. This seems to be exactly what you wanted to build around SVN.
I think that using ready made and proven tech is great idea. Would like to see it's progress if you really go that way.
I would strongly go AGAINST SharePoint - you'll tie yourself to Microsoft in manners that are hard to describe here. From my point of view, SharePoint is a tech that needs taking care of just for itself.
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 the lone .NET developer in an non-IT organization. I've been asked to develo ae .NET application using Microsoft Access as the back-end (existing DB).
I don't know where to start.
Since I'm developing by myself, what should I keep in mind to avoid during development? What situations does only a lone developer face?
Please include Microsoft Access specific advice in your answer, since that is germane to the question.
Where to start?
Choose a development environment (I would suggest Visual Studio 2008 Express or Professional, depending on the budget and the need for features of the Professional version)
Even for one single developer: choose a Version control system !!!! (Subversion has only little administrative overhead, fine for one developer)
Choose a .NET Framework version (3.5 is fine unless your application has to run on Win2K; for Win2K use .NET 2.0)
Choose a mature programming language (C# or VB.NET, what you or your boss likes best)
Choose a GUI technology (for a single developer, I would suggest using WinForms, unless you are going to write a Web application or a command line utility)
Choose a mature DB access technology (ADO.NET works for a lot of things, unless you have very high performance requirements that are better dealt with old ADO/OleDB or DAO)
EDIT: use Google to find some entry examples according to the choosen technology, or buy yourself a book. For example, here is one for C# using OLE DB to access a MS Access DB. This Access site is a good starting point, too.
EDIT2: make yourself familiar with "Microsoft Access" (the Office Application). Not because you are going to use it like a typical user, but you will probably need it for administrative purposes. And the VBA & SQL documentation included will be sometimes helpful, even if you code with C# or VB.NET
EDIT3: for reporting purposes, choose a reporting technology. There are plenty of possibilites here, depending on your needs, your skills and/or budget, for example
Plain ASCII or CSV reports (coded by hand)
HTML or XML reports
using Excel as reporting engine
using a PDF library like Report.NET
using a third party tool like Crystal Reports
You will find a lot of helpful links when you give "report generation .net" to Google, for example this one.
And finally: come back to SO and ask more concrete questions when you come to the point where you have them.
There might be other constraints, depending on what code is already existing in your organization. And I would avoid technologies like F#, WPF or Linq to Entities.
Your question is too vague to give more than just general advice. If you have already developed other .Net applications, then the approach to developing this new application should not really be any different.
Database considerations:
The only things to bear in mind when using MS Access as a back-end database are:
Scalability - MS Access does not
scale very well and is only suitable
for a small number of users
*EDIT: Numbers vary depending on the type of activity the users are performing - for a reporting solution, Microsoft themselves suggest that up to ~100 concurrent users is the maximum - this white paper provides more information *
Security - MS Access does not offer the same sophisticated levels
of security that you will find in
other database products (SQL Server,
Oracle, MySQL)
SQL Syntax - there are some subtle differences in the way you
write certain types of query for MS
Access
Other Limitations - MS Access does not support stored procedures, so all your data access code will have to use inline SQL Commands (command.Type = CommandType.Text)
The maximum database size supported by Microsoft Access is 2GB - keep an eye on the growth of the database
Design considerations:
Does the existing MS Access database already have some user forms and code modules in it? If so, you could use these as the basis for your application - MS Access uses Visual Basic for Applications (VBA) as it's programming language and there are no tools/utilities that I know of that will port VBA to VB.Net
Do similar applications exist elsewhere that could help inform your design?
Keep data access code out of your forms as much as possible - try to keep data access code in a separate class/DLL so that it is easier to maintain
EDIT: as others have suggested, try to avoid having instances of ADO.Net connection and command objects scattered throughout the user interface - put all database connection code in one class/DLL so that it easier to fix/maintain/replace. I'd also suggest putting all your SQL query statements in a separate class or module for the same reason. *
Follow any in-house guidelines that you, or others before you, have put in place.
Keep maintainability in mind - someone after you may have to make changes. Use comments in code and give your objects (forms/variables/function names) sensible names
Take regular backups of your code - put a copy on a network drive or USB drive every day
One point of advice, encapsulate all Access-specific code within a single class. The class should at least be able to:
locate the Access .mdb file
create and open all OleDbConnection objects
It's critical that all Connections are guaranteed to close, so wrapping their use in a using block is a very good idea
(Possibly) build and execute all OleDbCommands (removing the db-specific logic from the consuming components--they should be able to make data-requests and retrieve results while transparently creating the Connection & Command, etc.
For accessing the Access database, you could maybe have a look at NHibernate? As far as I know it supports Microsoft Access and using a library like that could perhaps make things easier if you are going to move the data to some other kind of database later on.
If you are already familiar with a .NET language and MS Access then my advice would be to start off by developing a very simple MS Access database and write a small .NET console application that connects to that database and performs some basic functions e.g. querying/inserting/deleting/updating. Then its just a case of builiding on top of this piece by peice, introducing GUIs/separate libs (dlls) etc on the way.
Unfortunately for you .NET Linq to SQL (ORM) does not support MS Access databases so you will have to develop your Business Objects from scratch (not always a bad thing!).
Here is a good starting point MS Application with C#.
There is a lot of good advice here, all I would add is be sure to build all your data access and modifying classes behind a well defined interface(s). I am sure there will come a time when this application out grows MS Access and having well defined interfaces will make upgrading to another database easier.