I know that the integration between umbraco and VS2010 isn't perfect. For example, things linger in umbraco because it stores things in flat files like umbraco.config. In general, when I delete things like document types or make certain kinds of changes to document properties in them, in VS I delete the umbraco.config, clean the solution and rebuilt before running the CMS. After that, I know the db keeps some things around, so I go into the Settings section and delete the approprite document properties, etc.
That said, I haven't yet figured out where umbraco is storing certain master pages/templates since, when I delete certain ones of those, when I clean and rebuild, the files will reappear (thought not included in the project). Can anyone tell me where the reference to these deleted templates lives in the umbraco SiteBuilder code so that I can get rid of them permanently?
If you delete a template within the Umbraco CMS itself, then this will not only delete the record in the database but it will also delete the physical file itself.
If you only delete the physical file, Umbraco will recreate the template based on the template record it has in the database.
i found the best way to use VS 2010 with umbraco is to install this extension http://our.umbraco.org/projects/developer-tools/visual-studio-2010-project-template which allows you to create the umbraco site as a VS project. This ensures any change you do to umbraco are picked up in visual studio as well and the best way to delete/create templates is to do it via umbraco as it creates references and and id to these in the database (if you do it in vs the umbraco settings that do this wont pick it up).
Related
I did the following steps:
I have created a new Umbraco instance by using the nuget package and visual studio.
I have deployed to Azure, using Azure DB as backend.
Installed the articulate package.
Added my project to version control (including App_Plugins folder, articulate dlls and so on).
I am able delete the umbraco installation and I can restore it completely from version control including Articulate.
Now I am starting to add content, articles, pictures and so on.
Think I do not need to backup the whole folder on the web server. I am doing regular backups of my Azure DB and I need some folders which are also filled with new content, like
media (filling with pictures which I am adding to my articles)
App_Plugins (keeping installed packages in umbraco)
App_Data/packages (file directory for installed packages)
App_Data/umbraco.config (keeping some content for Articulate)
So, is this everything I need to be able to restore the whole system by using the version control part, azure db backup and the listed folders?
Ideally for data/contents you should backup media and App_Data folders. However, if you want to backup Umbraco site (including cache files) then I would recommend App_Plugins, App_Data, Bin, Config, Umbraco & Umbraco_Client folders.
Hope this information helps!
Basically I follow the approach as described in the question. I have added the following files and folders to the Visual Studio project and then later to version control (I have just expanded the more interesting folders which are not part of the project file by default, but needed when you redeploy the solution from scratch):
As described the backend is hosted on Azure SQL.
Open Live Writer makes it very easy to host article content on another ftp server.
By following this approach it is very easy to redeploy the complete solution, e.g. for umbraco upgrades or major changes on the site.
When publishing a Visual Studio 2012 MVC website, there is the option to "Delete all existing files prior to publish". I've had this checked when publishing my websites, which I do over the File System, but this takes the web down until the publish is done. I'm wondering what are the situations where this option should be turned on.
I had situations where not all files that changed were being updated and the old files were being kept. Although I still don't know why that happened, let Visual Studio delete this files helped. Still, I will never save/activate this option in one of my profiles. Use it with care, I guess.
I had a situation in a MVC project where I moved a view file to the Shared folder. When I did a publish without doing a delete all, it left that file in the original folder. When I called the Controller method that referenced that view on the live site, it found the view file in the original folder before the one in the Shared folder. Doing a delete all first would have kept that problem from happening.
We started programming in a project that uses Agile Work Item Templates. Now, there is some history of the code that we want to keep.
Also, we want to change to a customized CMMI template, so it is close to CMMI, but customized, with slightly different work items, also some new/removed ones (for testing purposes, we set it up in a different project).
How can we now merge the source (and history) from the one project with the work items from another project?
From my understanding, you could simply export/import the work item types, but then, all the reports and queries as well as the dashboard would not get updated properly as well? So all scenarios we can come up with now result in a loss of version history (simply importing the current state of the source into newly created project using CMMI and then updating the work items).
Is there a better solution?
(using TFS 2010 and VS 2010)
edit: some useful information to be found here: http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/05/17/tfs-integration-tools-where-does-one-start-part-3-dust-has-settled-did-it-work.aspx - like me, you will probably especially run into trouble with the ProcessBuildTemplates
Have you considered using the TFS Integration Tools? I'm not sure about the successful migration of work items for Team Projects using different templates, but I've been able to successfully migrate code with its history between Team Projects.
We have some legacy Classic ASP websites to maintain, and are wanting to use VS2010 to edit them, due to familiarity because of lots of .Net work.
I can open the website inside Visual Studio.
I can configure IIS to run the website based on the working folder used in VS2010.
I can configure VS2010 to automatically open my default browser pointing to the correct location, using the 'Base Url' setting in the Properties page.
What I CAN'T do, is work out where VS2010 stores this value, as there's no mention of it in the solution file that VS2010 has created, and as there's no project file for the website, there's nothing there too. Yet, when I close and re-open VS2010, it somehow retains this information.
This is important to me, as I need to be able to commit all files to our source control for use by other developers and, ideally, not have them worry about setting this value themselves.
So, the question is: Where does Visual Studio 2010 store the Base Url when working on Classic ASP websites?
I don't know where this is saved, but in tracking things like this down in the past I typically take the following approach:
Open Visual Studio and change this one setting
Apply the changes
Look for all files that have been modified in the last 1 minute in the project folders and in the Visual Studio folders
You can be sure there will be at least a few other files changed that are not relate to this, but it should narrow your search. You may want to re-close VS before searching too, but that will modify other files as well (making for a slightly larger pile of changed files to sift through).
If you still don't have it, search the registry (but I cannot imagine this would be where it was storing anything project specific).
EDIT:
Just created a new project and played with setting this property. It is definitely stored in the .suo (Solution User Options) file for the project, in the root of the project folder as #Lankymart suggested (and is a hidden file if you are not seeing it). It is not stored in plain-text.
You may be able to access it programmatically here: http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivspersistsolutionopts.loaduseroptions.aspx
As there are a ton of absolute path settings in these files, moving it to other environments is not really an option. I would suggest you are stuck with project start up documentation that lists these settings as part of the project setup process. I think any other solution is going to be equally annoying|fragile (or worse).
Not sure if there is another way to accomplish what setting the base URL does without managing from the Start Options panel - that is likely your last-best hope for a solution.
My company are working at Sharepoint site that we are developing using Visual Studio. The actual installation at the customer is performed by scripts deploying the produced wsp-files. During normal development I mostly use deployment from directly from inside Visual Studio. Unfortunately I often run into problems when trying to deploy my solutions. We are using a server-farm set up, but each developer has their own virtual server, datebase instance and so on.
We have one project file that the define the basic content-type used for different department. This content-type typically define stuff like what period that the list item cover. Each department have their own project that uses the content type combined with department specific fields to form the final list.
One of my current problems is that when I make edits to the content type and deploy it the changes does not seem to propagate. Even though I rebuild the solution and deploy both the base project and the department project with success I still see the old version of the content fields when I create a new department list. Sometimes it helps to retract the projects, but often I literally have to restart everything before it works.
My question is if this problem is caused by Visual Studio not really deploying my new defintions or if there is some architectual aspect of Sharepoint 2010 that might prevent the change to propagate. What steps can I take to lessen the likelihood of the problem occuring?
Have you tried deleting the content type with Central Administration before doing a new deployment? I've found out that Sharepoint don't update/create content types when it finds other one with the same name.