I have migrates an application from VB6 to .Net 2005 and found ADODB.Recordset in that. Should I leave it as it is or should I change it with ADO.Net? Any insight about how ADODB.Recordset works in .Net environment will be helpful.
I would leave it as it is if I did not have a compelling reason to update it. Leaving what is working saves a lot of time.
Related
Is a VSTO application considered a macro as far as office is concerned? In other words, will macro sensitive antivirus software give me trouble? And will the Word trust Center settings need to be changed to allow macros?
Thanks.
A VSTO app is totally different from a VBA macro, and should not trigger any macro-related warnings. A macro is a script attached to the document; simply opening an office document could trigger some potentially harmful VBA code, without warning to the user. By contrast, a VSTO app is a .NET app which needs to be explicitly installed and accepted by the user on his machine.
Mathias gave us an excellent answer. I totally agree with that. But I also just want to add a little bit more things about VSTO here based on some of my own experiences.
VSTO add-in is basically an application-level extension for MS Office. It requires .NET framework & VSTO runtime to be installed on the target machine in order to run correctly (In some case, PIA is needed as well). VSTO runtime is not too good in terms of compatibility, and greatly dependent on Office version. For example, Office 2003 doesn't work with VSTO 4.
Using VSTO opens opportunity for .net programmers who'd like to create MS Office based applications. It certainly is more powerful than what VBA can offer.
But the downside of any VSTO application is the challenges in deployment. Although ClickOnce approach is meant to make the whole deployment a bit easier, the process is still not as easy as falling off a log, especially for deployment using Windows Installer approach. Special registry keys, permissions, and all that just give you a headache from time to time. Also API is not documented very well, code examples aren't enough either... Well, anyway, I think VSTO still has its potentials and hopefully Microsoft will provide better support in the near future and more people join community of VSTO development.
I'm leading a small software development team (4 people), and have just broken ground on a source-controlled SQL Server 2008 database project, with isolated development databases for each developer. I'm still implementing this one step at a time, but I'm envisioning each developer having their own database, with a naming scheme something like <ProjectName>_DEVELOPMENT_<TFSUserName>. This was all recommended per the MSDN articles I've been reading, but someone let me know if that sounds way off.
Anyway, we have a shared application solution that we've been developing for some time. In the past, we had no database version control, and just modified our database directly from SQL Server Management Studio when new reference data needed to be populated, or when we were testing functionality -- one change immediately affected everyone else. So with this new change, I'm wondering what the best way would be to have each person connect to their isolated development databases from the application solution. Prior to isolated databases, our connection to the database was specified in our application's web.config as a connection string. If we're each going to have our own database, the only way I can see it working is for each developer to set their connection string in their local solution to point to their personal database. But changing the web.config will check out that file in the solution, so developers will always have to specifically uncheck that file when checking in application changes to the baseline. Is there a less clunky way for each developer to use their isolated database when doing application testing?
I recommend that you not make the database names username-specific. Instead make the database the same name for each developer and always reference it via localhost (localhost\<ProjectName>_DEVELOPMENT). Then the same connection string will work for every developer.
MSDN's suggestion to use username-specific databases is better for a shared development environment. It's definitely not ideal for a localized environment.
Hi i have configured the basics of cruise control to make releases, and automated nunit test using just MSBuild. Now i'm wondering if is possible to deploy/versioning databases with this?
I'm a beginner at CCNet .So if is possible some suggestions or tutorials (if there are) . Also if someone knows a free tool for database deployment/versioning let me know.. i will be grateful.
Thanks in advance
Hugh
It isn't free but SQL Source Control from RedGate can do what you're looking for, assuming it's a SQL Server database. It has a commandline interface that you can use in CCNet tasks. The easy approach of just migrating up is... easy, the changes are applied to your database schema / data. There was an issue with v2x of the tool that they've overcome with 3, which is that if you were to rename a table column then it would delete the column and create a new one with the right name. Obviously that's quite a big problem if you've got data you want to keep, so with v3 there's the concept of migrations and this allows you to specify alter scripts so instead of dropping the column you could script the change non-destructively.
As far as I know, at this time, they don't have anything that allows you to roll back your version.
Otherwise you could take a look at database migration tools, there seemed to be some promise for these in .Net at least. There is also this post that has some other tools (again for .net) and then there's this https://stackoverflow.com/search?q=database+migration+tool which is not restricted to any language but is general database migrations
If you're still looking for ways to version and migrate databases, one such tool is dbdeploy.net . I've hosted it on github after forking it and doing some work. Latest version is fully up to date and has some interesting features (done by someone who also uses it and sent a pull request).
does anybody know a good, flexible and free component for automatic application updating beside ClickOnce (not necessarily .NET only)?
In the past there was the Updater Application Block from Microsoft. But as far as i know its not maintained anymore.
What Technology are you using to keep you applications up to date?
We have designed our own updater logic based on WiX & .NET for our .NET apps. Logic is fairly simple and couple with continuous integration (so that we can fire a new release in a single click). Everything is released as open source. You can have a look at the code at http://code.google.com/p/lokad-sdk/ and more precisely at http://tinyurl.com/kwrhvo (direct app source code).
Try PADUpdater it's freeware and doesn't need any configuration as it uses your PAD.XML file to get the settings.
We are in the process of selecting a workflow solution for a company that uses Microsoft products end to end. Given the news on WF4, in that it seems to be essentially a rewrite of previous versions, is it a wise move to back the current version or should we be looking elsewhere?
Ie - is the current version so bad that we would not be wise to try and use it?
Haiving just launched a project which .NET 3.5 and workflow I'd say that the current release of WF is good enough to use and run with. It has helped us to get a product out quickly (we have the usual feature creep and requirements changing weekly). However, I have a list of complaints with it:
The workflow designer will drive you insane because it is so slow (in certain circumstances) and re-arranges your state machines as it sees fit.
There is no built in upgrade strategy for keeping your old workflows running once you do a bug fix release. If you are going to use WF think carefully how to do upgrades early.
Itegrating with WCF (the send and recieve activity) hide the WorkflowRuntime from you this makes it very difficult to understand what is going on on the hood.
Its not easy to unit test them. There are ideas out there but none seemed particulary easy when we started this WorkFlow Unit Testing
I like the ideas and potential of Workflow based development, however I am not in a hurry to repeat this experience and would probably stick without it for long running processes. One place I would use it again would be in a short, complicated process (like a rules engine for working out prices).
Maybe it is a little late for you, but now that WF 4.0 is released in beta, other people thinking the same question can consider backing the 4.0 horse instead of 3.5 horse.
This goes some way to fixing the following problems:
•The workflow designer will drive you insane because it is so slow (in certain circumstances) and re-arranges your state machines as it sees fit.
[Designer Perf Improved]
•Its not easy to unit test them. There are ideas out there but none seemed particulary easy when we started this WorkFlow Unit Testing
[I think it's a little easier now, some of the introduction to workflow samples include plenty of unit testing]
My understanding is that Microsoft will provide backwards compatibility and/or a migration strategy to the new WF, so I would guess that you are safe to use it. However, I have heard from other developers in my organization that the current version of WF is extremely painful to use. If you have the budget (and depending on the complexity of your workflows), you may want to consider K2: http://www.k2.com/en/index.aspx
I, as a workflow developer, think that current version is painful to use. This is not surprising as this is a v1.0 software out from microsoft :)
I think you should first consider your expectations from a workflow software. Do you have a well defined list of expectations from WF? Acutally I am wondering content of such a list. Maybe we can help more detailed on each topic.
I don't know why people have such negative impressions about WF. Sure it has it drawbacks, but I thought it was pretty useful. The one major issue I have about it is the lack of support for upgrading existing workflow (bullent #2 in gbanfill's list).
Another point to use the current version is that "Dublin" (Microsoft new App Server) will be built on WCF & WF .NET 4.0 but will gladly host 3.5 WF's. So you will be able to migrate to that without a rewrite.
Just a quick note to mention that Visual Studio 2010 CTP contains a new updated WF designer as part of the Oslo objective.