I am dusting off a number of old projects that we have in production and would like to upgrade the vbproj files to the latest version. Currently, ToolsVersion="12.0". New projects created in VS 2019 are using 15.0. My current projects have been repeatedly updated since something like VS 2003. However VS 2019 is not offering to upgrade them further. Although maybe I am missing something.
I plan to set up a side-by-side environment so I can use the designer content. I would really like to begin with project versions that are up-to-date. These current projects have been repeatedly updated since something like VS 2003.
A cursory review shows that the vbproj content is quite different. Is there a recommended way to upgrade? One alternative would be to create new projects using current templates and copy the source over. But there are about 32 projects that include WinForms, Web and class library projects and that's a big task. Another approach would be for me to manually merge the old and new vbproj files, something I am not sure I can safely do.
Any ideas?
VS 2019 - how to upgrade Visual Basic .NET projects
In fact, you have missed too many versions of VS and this document shows that VS2019 will not allow to upgrade VS2003 project directly.
Because there are too many different versions, there have been great changes from the project structure to the construction mechanism to various details, and some have even been removed from the new version VS.
The safest way is to upgrade the project step by step(a version by a version), but it is not unreality since VS2005, VS2008 are no longer maintained by Microsoft.
Or you can try upgrading your project step by step with VS2010 directly as an intermediate, but due to the large gap between the two, there will be various upgrade errors. And there is no such tool or easy approach to upgrade directly.
Actually, the best way is just creating new projects in VS2019 and then migrate your old project content into your new projects.
This is certainly much clearer and easier than if you were to correct errors in more than 30 projects later. And old projects with a gap of 16 years are worth the time it takes to re-create and migrate them in vs2019, which will take a long time but save you unnecessary and tedious errors.
In addition, do not forget to make a backup just in case.
Hope it could help you.
Related
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
I've written a bare-bones ap in Visual Studio 2010, Express version. It does what I need and several others are using it successfully. I'd like to add features to it, but I don't want to foreclose the ability to make corrections to the present version.
How do I make a fork in the application for this purpose? Google has been no help in this case, and I've tried several incarnations of copy and change names etc etc.
Ensure you have a Source Code Revision Control System in place (Subversion, TFS, Git etc.), and then create a branch. That way all names stay the same.
One technique is to create a branch (from the trunk, or a previous branch from trunk) for each different production version you want to support. That way, merging chnages up/down between versions and current development is (usually) relatively straightforward.
Even if you are not using Subversion, the 'Red Bean' book is a great place to learn about branching strategy.
Visual Studio 2010, Express edition doesn't integrate directly with source control systems. This is one of the product limitations (i.e. what makes it the 'express' license).
I would recommend either:
1. using a product like SVN or Mercurial, which you use outside the Visual Studio IDE
2. depending on the complexity of the changes, you may want to look at conditional compilation. It's kind of like a poor man's code branch.
I absolutely love the Source Code Ouliner power toy that I use in VS2005 but am upgrading to 2010 and it seems they haven't yet released a new version. Is there anything similar that shows you a basic outline of the file you are currently navigating?
ReSharper, amongst many other features, has a File Structure window which does the same as Source Outliner.
For a free one, try the Solution Navigator in the Microsoft Productivity Power Tools.
Like you, I found this a totally great plug in that saved on the order of minutes per day. No more searching for functions! Luckily Source Outliner has been re-created for VS2010 and is still free. However, sbohlen updated it and it now runs on the (free) DXCore environment. I have been using it ever since I upgraded to VS2010.
You can read along as I got this set up, downloaded all the parts and got it running.
http://unhandled-exceptions.com/blog/index.php/2010/05/23/plugins-for-dxcorecoderushxpresscoderushrefactor-pro-201014-rtm-available/
The download is here:
http://code.google.com/p/dxsourceoutliner/downloads/list
You will also need the DXCore community installer from http://www.devexpress.com
But as a ReSharper user for years now, I will use the File Structure - same sort of view and already built in to R#.
I am rather new to Sitecore and would like to know a bit more about the regular approach to a new project. I'm therefore willing to listen and try out some of the experienced Sitecore developers solutions. I have alot of questions, i won't ask them all. I am just very curious to the approach other people have.
What would be the best approach to start a Sitecore project?
How would you set your project up?
What will be your approach looking at the recycling of code in future projects?
In short: What experiences do YOU have (if you have worked with or are working on Sitecore projects) and how would you recommend other people to work with Sitecore.
Right now we are busy on building Sitecore blocks that we can just recycle in other projects but i know for sure there are 1001 handy tips and tricks out there. I hope we have some Sitecore pro's # stackoverflow that could help a bit.
Here is some general setup info, based on how we do things.
Subversion
This is not Sitecore specific but we set up our repository like this
branches - This is used for working on big updates to the site that may take a while. Say for example I wanted to update how all of the sidebars on the site worked, and this was going to take a few weeks to complete. What we do is create a new branch, and set up another sitecore instance for this dev branch and do what we need to do. When it is complete we merge it back into the trunk for testing and deployment.
tags - This is used for keeping a copy of code that will never be merged back into the trunk (that is the difference between this and branches), so for example when we deploy an update to a site we can create a tag of said code so we can go back to it if necessary.
trunk - The active code, anything checked in here should always be deployable.
The Trunk
This is where we are actively developing/fixing bugs, depending on which part of the project that we are on. We set it up something like this (as an example the project is called TheProject)
We keep our solution file at the root of this folder, this will reference the various libraries in the src folder as well as the web project in the website folder.
docs - A place to put documentation about the site. I strongly suggest that as you complete features/sections you write up a little guide about any special knowledge needed for it to work. So say I am working on a featured content box on a landing page. This box will automatically pull some content unless it is explicitly overridden. What I do when I complete something like this is I write a guide for the customer, using a lot of screenshots. I send the guide to the customer as well as put it in the docs folder. This both helps the customer train their staff, as well as helps new developers come up to speed with how things are done.
lib - This is where we keep any DLLs we are going to need to reference in our projects.
test - A place to put unit tests.
src - This is where we keep our project specific library code. So in here we would have a folder called TheProject.Library, and in there would be the visual studio project for said
web/Website - This is where we have Sitecore installed and is the root of the site. In here we have a project called something along the lines of TheProject.Web. In the project we add all of the general stuff like the web.config/layouts folder and so on.
General Sitecore Code Library
One the best things you can do is from the start setup a general Sitecore library that can be added onto over time. Then when you write any code for a project that is not only applicable to the project, you can add it there. It may seem obvious, but this will really help in the long term. You will end up with much more solid code, see link text .
So when we are done with all this we have something like this as a solution/project structure
TheProject (The solution)
TheProject.Library
TheProject.Web
MyCompany.SitecoreLibrary (our general sitecore library)
Tools
This is another general thing, but I find it can really help speed up Sitecore development. If you find yourself doing something over and over in Sitecore, using API write a tool to do it for you. This not only helps with solving whatever problem you are tackling, but also helps to get you more familiar with the API.
Resharper
This is more of a general .NET development suggestion, use Resharper(http://www.jetbrains.com/resharper/index.html). I am sort of a a Resharper fan boy, it makes so many things with development easier and quicker. In my mind the biggest advantage though is how easy it makes refactoring code, which is really important to do over time to keep things clean and understandable.
I hope some of this helps.
Gabe
This is, as you said, quite a big question. Here are some of my thoughts:
Developing Environment
First of all when I start a new project I install Sitecore on my developing environment and I make sure everything works. Either during installation or after I place the databases on a separate SQL-server and change the connectionstring accordingly.
I open up Visual Studio and create a solution and include the files needed. I create some kind of HelloWorld rendering and try building the solution so that I can verify that everything is working as it should.
When everything is up and running I create a zip-file of the whole solution, including the data-folder. Now it is time to add this to some kind of version control system, in my case Subversion.
I add the zip-file to subversion and also add all files that I think will be changed during the project, usually I tell subversion to ignore the sitecore folder, this speeds up performance drastically when checking in files.
After I perform a commit-action the other team members of my project can check out the code and start developing (after unzipping the zip-file, off-course)
We all work towards the same database although this goes against Sitecore recommendations, we havent had any problems with this approach however items in GUI created/changed by one developer take some time before it is created/changed for all the others.
We could off-course develop several different projects using the same Sitecore installation but since almost all customers use different versions of Sitecore we have found this approach a bit cumbersome.
Often we set up an automated build-server but this is a whole other issue.
Reusable code and renderings
I would like to say that we create neat packages based on the same codebase that gets reused between projects but unfortunately we are not there yet. Today it is a lot of cut and pasting between solutions.
Uploading code to customer
This is done via sitecore packages, normally with some kind of dynamic selection for what files to include, say all ascx-files in a specific folder changed the last 5 days.
There you have it.
Take a look at this series.
Especially the component architecture part have increased our level of reusability.
When you create your Visual Studio's project in Sitecore's web root folder and you will keep all Sitecore's dlls files inside bin directory, don't forget to add to project's references all these files:
bin\ComponentArt.Web.UI.dll
bin\HtmlAgilityPack.dll
bin\ITHit.WebDAV.Server.dll
bin\Lucene.Net.dll
bin\Mvp.Xml.dll
bin\Newtonsoft.Json.dll
bin\RadEditor.Net2.dll
bin\Sitecore.Kernel.dll
bin\Sitecore.Logging.dll
bin\Sitecore.NVelocity.dll
bin\Sitecore.Zip.dll
Because when you CLEAN your project and you will have reference only Sitecore.Kernel.dll (in most of cases), you will lost most of dlls from bin directory!!
I have a small diagnostic VB.Net application ( 2 forms, 20 subs & functions) written using VB.Net 2008 that targets Framework 2.0 and higher, but now I realize I need to support Framework 1.1. I'm looking for the most efficient way to accomplish this given these constraints:
I don't know which parts of the application are 2.0-specific.
I could reconstruct the forms without too much trouble.
I need to support SharpZipLib
My current idea is to find and install VB.Net 2003, copy over my code and iteratively re-create the tool. Are there better options?
Your app sounds small enough that I would create a fresh project/solution in a separate folder for the 1.1 framework, copy over the necessary files, use the "Add Existing Item" option, and then build. All the problems will bubble up to the surface that way.
A rather "ugly" approach, but it'll show you everything you need to fix up front.
Probably not. If you don't understand which bits are 2.0-specific, you're probably going to have to go the trial-and-error route. However, you can probably save yourself quite a bit of work if you go looking for generics beforehand. In my experience, those are the most numerous 1.1-incompatible bits that tend to make it into my code.
If you can gets your hands on VS 2010, you can (finally) target multiple frameworks. So within one project, you should be able to compile your 2.0 project to 1.1 and see what breaks.