Is it possible to uninstall the Tridion SP1 HR#1 hotfix from the CMS and leave the DB Updates in place? We experience very slow behavior of the GUI since applying the hotfix (maybe related to TMS service failing?) and need to go back to SP1 - however, we have made content updates to the DB since we applied the hotfix and would like to know if SP1 is compatible with the HR#1 DB Updates.
I realize this is a very specific issue - but maybe someone else has needed to rollback to SP1 for a different reason?
There is no supported way to roll back the upgrade nor is there a supported way to run an older version of the product on a newer database.
The closest you can probably get is restoring your database backup and install a plain SP1 on a new box. This is one of those cases where having a virtualized environment would help, since then you could probably roll back to your previous snapshot of the VM (similar to how you restore the database).
Problem was very slow GUI performance after applying HR#1. On saving a Component the World Server Connector writes errors into the Tridion Event Log. I opened a case with Customer Support and will update here when I have the solution.
Advice - if you are using the World Server Connector - do not install HR#1 yet. Wait until a hotfix is created for this issue or a solution presented from Tridion.
We are not rolling back - just going forward! :) We'll leave the World Server Connector off the system until we can make sure HR#1 and the WSC are happily working together.
Related
I was wondering if someone could help me sort this out.
Hotfix vs Patch vs Update.
I have look around the website but it only mentions about programs.
From what I understood,
Hotfix is to fix a certain bug and not always will be public announcement.
Patch is fixing few bugs and its public announcement.
Update is adding new content (as well as fixing bugs)
but isnt Patch used for new content as well?
I'm a bit confused with those terms
HotFix come in the form of a configuration change to workaround a problem or to fix a running application or server with minimal down time.
Patch is typically an update to existing code and delivered in binary form to fix a specific issue, bug or compatibility problems.
Updates can be used for enhancement or to bring an application up to date (and possibly contain multiple fixes rolled up).
We own a small company and develop asp.net websites. Here is our work procedure:
We have a server at the company with Sql Server 2008 and IIS 7.5 installed on it. All our projects including the database and website pages are on the server. We connect to the server and edit the files using FTP, so any change to a web page can be seen at once. The programmers (less than 10 programmers) connect to the server using Visual Studio 2010.
Now we want to include source control system in our work. The problem is including a SCM in our work requires changing our way of working.
Does anyone have any advise on setting up the working environment?
Thanks in advance.
You first need to decide on what type of SCM you are going to use - centralized or distributed.
One centralized SCM is TFS - this is from MS and integrates very will with VS. I believe there is an express (basic) version that is free, but the other editions are quite expensive.
An easy and free centralized SCM to start with is subversion - you can install the SVN server on your server and setup a client for each developer.
A distributed SCM does not have a server - a popular one is GIT.
Do read up on all of these before deciding. You will also have to figure out a good workflow for your team. Start with a small project so you can gain understanding and minimize the cost of mistakes.
So many ways to do this :)
One way is to use something like http://beanstalkapp.com/ to store your source code under SVN. Each developer then has a local copy of the code to work on and a good history of changes is kept when developers commit their code (at least daily), and these changes can be emailed around to the team if you want them to be. One member of the team is then tasked with uploading the latest SVN code to the testing server once it's tested and approved locally (probably at the end of each day).
I'd recommend your developers install http://www.visualsvn.com/visualsvn/ Toolbar into Visual Studio if you use SVN.
As an alternative to hosting your SVN repository with someone like Beanstalk, you could use the free http://www.visualsvn.com/server/ which cuts out the need to upload the latest code to your testing server, as it'd be stored right there and updated on each SVN commit. But this adds an overhead in terms of backups etc.
Let us know what road you go down in the end.
Few months back I saw TeraData Express Edition. I have no idea of this beast. I want to know whether it still comes with Express Edition and whether it is a good idea to use this database for Windows based mid-sized apps.
It really depends on what you want to do with this application. From an application perspective, a great weakness of Teradata is that it does not support read committed transaction isolation. If you are attempting to use Teradata as an OLTP database, then you might want to try something else. If you are using it to crunch numbers, then yes, go with it. The one issue is that Teradata Express Edition is not supported that well. Express edition is essentially a snapshot of the database for a certain release. If you find and report a bug, it will take a long time for you to receive a fix. Teradata only releases the express editions once per db release. However (imo), if you buy the real version, you will receive a pretty quick patch which will be rolled into the database software.
I use teradata in my technical support work. I work on database middleware, and Teradata is one of our supported data stores. Define mid-sized? 1-200 transactions per second? I'd stand ANY commonly used database up against that. 10000 tps? Maybe not - maybe you go to the enterprise edition.
Okay today, as most of you noticed Framework 4.0 has been released. I've been working on a project which is being built on framework 3.5. Since I want to use dynamic keyword and most of the asp.net features like Tableless Menu Control, ClientIDMode and clean web.config etc. I am kinda urging to migrate the unfinished project to 4.0 but I am little hesitating about that.Some times I think it is way better to wait for SP1.
So what do you think about it? You guys will migrate to unfinished projects or will still hang out with 3.5 for a while.
Thanks.
The .Net 4.0 runtime environment has been out for a while (mind you not RTM, but RC1 and so forth). A lot of people have tested it and I would guess that almost all of the bugs have been shaken out. There should be no problem switching at this point. They have introduced a number of items that improve .Net. Are they necessary, no, but they can make programming in .Net easier.
You can always download 4.0 locally and test it out on your project. Worse comes to worse, the project blows up and you reload it from your source control system.
What you should be aware of is that there are breaking changes in both C# and VB.Net in 4.0 runtime environment. You'll need to watch out for those.
The following probably applies to most framework-base development.
Do the new features save more time than fixing the old things the upgrade breaks?
If you're going to waste lots of time making old things work, perhaps you're better off just to sit it out on 3.x and port to 4.x at a later phase.
If you really need features from 4.0 and would have to spend time implementing them yourself, perhaps it's a net time saving.
Can you support this version of the framework? (ie can your server people handle the upgrades and monitor things okay?)
If your server bods can't make this work in the field, give up now. I don't know your organisational structure or who runs your servers but I know some companies have a pretty thorough testing regime they'll put software through before allowing it. As a brand new version, they might be weary.
And let's be frank, just because something goes through several pre-release versions, they don't catch every bug because they're rarely used in production scenarios. You know the drill.
And if installing 4.0 on the server breaks old things, you might be waiting a long time.
Is your project's launch likely going to be after the first round of bug fixes?
If you're developing this for 3+ months away, you've probably got enough time to sort the platform issues, fix the code issues and get framework bugs reported with the (blind) hope that they fix them or you can work around them safely.
If you're launching tomorrow, it's not enough time to test it.
I will only upgrade when there is a need to do it. For example I have one application that must use features delivered in .Net Framework 4. So that application will get upgraded ASAP.
I have another application that is 3.5 with no driving need to upgrade at this time. That one will get upgraded when time and budget allows.
I just started at a new company that has 99% of their code written in classic ASP (most of it poorly written) and part of the reason they hired me was because I had worked with both ASP and ASP.NET in the past. The ASP.NET experience was VB.NET but I've worked with C# in college but I prefer it just because I've worked a lot with PHP in the past and when I'm not focusing I just start typing C syntax and have had many occasions here in ASP where I end lines in a semi colon just out of habit and have to go back and delete it.
But I digress, basically I just don't have the knowledge I need to make the best decisions on things have made notes of some key processes that I'd like advice on:
Version Control - truth be told I've never really used it. On my own I just never had that whoops moment to push me to use it and shops I've worked in have always just thrown caution to the wind. Would like to know what you all think I should use as far as the server side and
Local Dev Environment - Probably something I'll just quickly Google but I want to setup a local dev environment so I can test stuff without having to FTP it somewhere first.
Pushing Changes Live - I've never really understood the step between checking something into version control and seeing it live, is there some sort of automated system that can go "hey I see you checked in, let me see what's different between this and the live version and push the affected files" – possibly just a lack of vc understanding all together: (
IDE - Downloading VS2010 Beta 10 now, hoping it's stable
MVC.NET - Easy to pickup? I always hated the whole concept of Web Forms, seemed like it didn't ultimately fit the Internet the rest of the world is developing.
Anything Else - Like I said I'm relatively new to this stack so I'd love any advice I can get early on to avoid any "shit, I wish I knew that 3 months ago" moments.
Version Control:
Definately have a look at SubVersion, its free, we use a paid-for hosted service called Assembla (www.assembla.com) but you can install the server on your network. Themost popular client is called TortoiseSVN (http://tortoisesvn.tigris.org/) its also free.
You can also have a look at VisualSVN (http://www.visualsvn.com/) which integrated into the VS IDE, their site also has a handy SVN server installation.
Local Dev Environment
Local IIS or Built-in VS web-server in VS are both fine, it really down to preference I think. Opening a website (File-system based) rather than IIS based seems to work quite well for us.
Pushing Changes Live
ASP is very page by page based development and doesnt require compiling, copying files up to a test or production site is quite easy. Depending on how you compile/publish your asp.net site, you will need to consider how you compile library code and publish your web application/website.
I would recommend starting off by using SVN to commit changes and to update test/production sites.
IDE:
I would recommend updating to the latest Beta version of VS2010 and use that.
Anything else:
Consider the rollout, are you replacing everything before going live?
Consider adopting an existing framework, use an ORM, or Business Objects framework, possibly even use Code-Generation. Have a look at CodeSmith, it has various ORM/Business Object Frameworks associated with it. (these will use various teqniques and technologies in the .net framework, which you will need to learn)
Look at the basic structure of the site:
Consider asp.net WebForms (Applications) or MVC (Websites) [yes, this is a very basic analysis of the differences]
Site Membership and Permissions: Have a look at the MembershipProvider, RoleProvider and build your own.
File System: Consider how and where you will upload files.
Separate UI into re-usable UserControls.
HTH, Good Luck you have a lot to do...
Wow. lots of questions here:
Version Control - Look into Subversion and Git. They represent two kinds of version control, you might like one more than the other. Git is free for open source projects.
Local Dev Environment - I would recommend using the built-in web server in Visual Studio. You can right-click a page in your solution explorer and say "view in browser". Then it will just compile it right there and open up an instance of the local web server.
Pushing Changes Live - I am not gonna offer advice here. Someone smarter than me will surely do so.
IDE - Yeah, just stick with the current version of Visual Studio. If you don't have any active (for pay) projects, I think the VS2010 is a good idea because it supports the newest upcoming features of asp.net and by the time you learn them, it will probably be released to the public anyways.
Anything Else - It's worthwhile (from getting work perspective) to know WebForms in and out. But I would highly suggest learning ASp.Net MVC (if, for no other reason than, "it's more fun").
After reading Mark Redman's answer, it triggered something for me. I would recommend (as he does) that you investigate some sort of ORM. I use SubSonic and really love it. Bu t there are lots of options out there.
Those are my 2 cents.
I'm going to focus on versioning and project tracking here. Development environments for ASP.Net are well documented.
Version Control - I use SVN (version control) with Tortoise SVN (windows client integration) and Trac (project tracking). SVN and Trac both run on Apache (a web server).
Pushing Changes Live - Commit your changes to SVN from your dev machine, do a SVN update on your test site to pull down the latest changes from the repository, run tests, then do a SVN update on your production site.
Anything Else - In this scheme Apache, Subversion, and Trac will be running on a server that is NOT your development machine and hopefully (but not necessarily) also not the same server that is running your production IIS.
Check out:
Apache HTTP server: http://httpd.apache.org/
Subversion: http://subversion.apache.org/
Tortoise SVN: http://tortoisesvn.tigris.org/
Trac: http://trac.edgewall.org/
One thing to take account of is basically going from Classical ASP to ASP.NET is about as similar as going from COBOL to ASP.NET. Everything will basically need to be a complete rewrite (especially as you said there were poor development practices in the original codebase)
Version Control: Definitely use it, there's also Team Foundation Server which if you can convince the company in the value of purchasing you a MSDN subscription TFS is included at no additional cost for 5 or less users.
Pushing changes live: I currently use Web Deployment projects (not sure if they're compatible with VS2010), TFS is also a build server I just haven't had time to setup the responsibility for that. If you take advantage of TFS fully I'd also recommend looking into a continuous integration (CI) tool something along the lines of Jetbrains's TeamCity or CruiseControl etc.
Local Dev Enviroment: Get Jetbrains's Resharper! This is the number one most important tool to developing software in .NET second only to Visual Studio itself!
Anything else: Learn generics and lambdas/expression trees both are integral to proper software development in .NET and both are moderately to extremely complex topics (IMO).
Version control: I see many recomendations of SVN here but... it's just outdated. Use GIT or Mercurial. They merge algorithms are more robust. The are faster and safere because they are distributed. They are more flexible - you can construct a workflow model that suits your company well while there is basically one way of using SVN.
Pushing changes live: After you have version control, the next thing to do is making a Continous Integration server thah repeatedly checks out repository and perform automated build. You can get immediate information who and where made an error. You can make this build do anytking you want: perform static code analysis, unit tests, deployment. You can make several builds - one, automatic, that builds a project and deploys it to a testing environment. And another one, triggered manually, that will deploy to live. I worked with Hudson, Jenkins, CruiseControl.NET, TeamCity and I've found TeamCity to be the most user friendly tool of that four.
Local dev env: Althoug IIS Express (that Visual Studio built-in) is OK in many cases, you have to know where it differs from the 'real' one. I would just recommend using the full IIS 7.
IDE: Visual Studio + Resharper + Notepad++ + LINQPad.
Anything else: Have some bug tracking/planning software. Even as simple as http://www.trello.com, but use it. My favourite is http://www.pivotaltracker.com
Introduce code review into the workflow. http://www.reviewboard.org might help.