Tag Info

Hot answers tagged

27

The three points you listed seem fair: It is a fairly important project so it has to work - a C# solution would not be as stable or work as well as the existing a VBA-based solution. Indeed, later, you tell: "I would like to take this opportunity brush up on my C# skills as I am currently not as competent in C# as I am VBA" (emphasis mine). In other ...


12

I would support going to C#. Others have covered your points very well, so I won't rehash what they've said. There are definitely a lot of good reasons to stick with VBA. However, one of my employers did an impeccable job at creating meaningful documentation. So much so that design decisions were actually written down with justification - if only all ...


10

I hate to say it, but your arguments just don't hold water. Unit testing. This has been a solved problem for a very long time. There are many Unit Testing frameworks out there. Pick one. You should have been doing this already. I recommend ours, because it integrates into the IDE and provides other great features. Source control This one is a bit ...


9

You'll want to read up on the term "technical debt". If time & resources permit, it is much better to do any code clean up immediately while the problem is fresh in your mind. Leaving clean up as a to-do item for others can turn into a very bad habit. These to-do items are rarely addressed, and after many years can lead to such a horrific mess that ...


4

You can point out that even Microsoft states in this article: Updating the code to improve features or to fix bugs would require that the Office artifact be re-emailed, re-structured, and re-worked by every single user and in every single file that has been using the customization. The article is about different approaches of developing stuff ...


4

It really depends on how you intend to move to C# (ie what technology you are going to use). If you are going to use OpenXML, then you are talking a total re-write which, if you have a solution that works, isn't recommended. If you are talking about using Interop, you may find that the process is surprisingly smooth. I've moved a lot of code from VBA to C# ...


2

I am in same position, of having a very large (20k+ lines of VBA code) application built into an EXCEL workbook. Upon testing with Office 2013 it simply fails to work, believed due to changes in the sequence of start-up event in the new office model, and possibly more strict enforcement of EMET. I am thus in the position of doing a crash-conversion to C# and ...


2

I would like to take this opportunity brush up on my C# skills as I am currently not as competent in C# as I am VBA and I'd like a project like this to take me to the "next level". Be honest. Do you plan on sharing this information with the other people involved in making this decision? If not, I would place the entire blame on you if the project ...


2

Here's the highlights from research from other sources (originally from revision 2 of the question): Should I use one database per application or share a single database amongst multiple applications Supporting multitenancy MSDN Multi-Tenant Data Architecture SO How to create a multi-tenant database with shared table structures? CloudExpo SaaS - ...


1

We don't know all of your requirements and resources, so I can't possibly say what is best here. However, there are some things to consider. Resources Do you have the knowledge to build this as an Asp application? Does your staff know enough to build and support it? If you don't have any professional devs on staff to support this, Access may be the way ...


1

You may think in terms of packages, which makes the location of the source irrelevant. For instance, if you work with C#, your shared library can be published as a NuGet package. When you refactor the library, you don't cascade anything immediately to work application; instead, you publish a new version of the package, and when you're ready, you migrate the ...


1

Personally I include only the source files WRT source control. Its a rare case when generated files should be added to source control - maybe if they were generated once and never changed, and the generation step is lengthy or complex, otherwise I can't think of a good reason. For compilation - if they need to be added to the project then I tend to add them ...


1

Let me offer my take on this question. Although you certainly can simply use your .SLN file as your 'build process', the file itself really doesn't constitute a build process. The Solution file is really just a part of Visual Studio and is used for development. But Visual Studio is only a part of the build and release process. You can't rely on Solutions ...



Only top voted, non community-wiki answers of a minimum length are eligible