So this is a bit of a vague question and I apologize but here goes nothing.
I am in the process of creating a SP2013 test farm that is an exact copy of our SP2010 production farm. When I mount the main content db for our main site collection I get a missing feature ID error. Here is the problem I need help with...
The solution that should have this feature is deployed to the farm already, however, as I was not working here when these solutions were made I don't know if I'm deploying the correct .wsp file. There are about 8 revisions so I naturally deployed the latest one.
So...
1. Would feature ID's change from version to version?
2. Is there a way to see which .wsp is deployed to my production farm.
Thanks for any help!
Featuer ID will not change from version to version. you can see installed features from template/feature folder under SharePoint Hive (either 15 or 14 hive based on your sharepoint version).
Hope this helps.
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
I have developed a very simple Provider-Hosted App which I was deploying to our SharePoint Online Developer Site.
Testing was going fine, and I had deployed it several times to the site, before I suddenly received this error in Visual Studio 2012 after I hit F5:
Error occurred in deployment step 'Install app for SharePoint': A different version of this App is already installed with the same version number. You need to delete the app from the site and the site recycle bin to install this version.
The thing is, I had just deleted / removed my app from the Developer site and from the recycle bin right before I received this error.
Not sure if this is relevant: but one of the changes I made to the program was to give the App Write permissions for the Web scope via the AppManifest.xml file.
I'm not finding anyone with this exact error on Google search results, so I thought I'd be the first to post it here.
Any help / ideas? I'm fairly new to developing for SP13.
Thanks in advance
First off welcome to the world of SharePoint dev. SharePoint can be quite painful with holding onto things, but the solution in your case is fairly easy - anytime you make a change to the AppManifest increment the version number. This is done on the general tab of the AppManifest, or if you're directly editing the xml then it should be the third item in the App tag.
Changing to 1.0.0.1 should fix your problem straight away, it is also a good habit to get into as then when you are deploying an app manually (not hitting f5) you will be able to update the old version of the app instead of having to completely remove it.
I am newbie in TFS 2010.
I have installed TFS 2010 on server and successfully connected.
I am doing check in for comitting my changed file and get latest version from other computer. Most of the time it works fine but oftenly js or style file gets corrupt.
Suppose i have two systems connected to TFS on server.
System A
1- I do change in abc.aspx.
2- I check in.
3- I keep on working on system and edit 4 files.
4- I check in.
System B
1- I get latest version.
2- I get abc.aspx changed.
3- I am doing work on some other files.
4- I get latest version, from System A i receive change in 3 files where as 4th file remain same.
Some times the project gets corrupt in a way the design gets bad and aspx page disturbs.
I tried to find help on websites but there is not much tfs help available. Please guide me where i am wrong.
You may try to clean client and server caches. See http://www.ewaldhofman.nl/post/2009/07/06/Clear-the-cache-of-TFS.aspx
Some background to my problem...
We are currently using ClickOnce to deploy part of our solution which was working a treat until we encountered a scenario where we are now required to have multiple instances of our application installed on the same PC. We are able to achieve this internally and have this working perfectly as we know what instances we have so our build process will update AssemblyName to include the instance name before publishing the installer, this means we are able to have multiple instances on our PCs internally (ie, test, live and demo etc).
Our external deployment process is slightly different, we take one of the ClickOnce installers created in our build (along with all our other components that make up our application) and as the ClickOnce installer is deployed on a server we update the app.config along with the manifest files and resign so they now have client specific details. If a client chooses to have multiple instances of our product installed the ClickOnce will now fail when a second instance is installed on a desktop PC as all instances share the same assemble name.
So finally to the question, does anyone know of a way to update the manifest etc after the clickonce package has been created to allow multiple instances to be installed? We could go down the route of building many clickOnce installers but I dont think this will really work for us, is there perhaps an alternative to ClickOnce which provides a similar upgrade experience for non-admin users?
Hopefully someone will be able to share their experiences and help me resolve this.
Thanks in advance
Doug
I don't know of another technology that allows such a simple auto update process. So sticking with ClickOnce... I think this link might be useful. It explains what you need to do to have the same app installed twice. Essentially changing the assembly name and product name should do it.
Hope that helps.
Greg
I'm using Publish/Web Deploy to deploy an asp.net aplication from Visual studio 2010. It works perfect, but there is a problem. If the new release is not working as expected, the old version is already replaced by the new one and there is no easy way to roll back to the working version. How is this best solved? I wish it was possible to keep the old version on the server so I could just switch back if needed.
With WebDeploy there is no built in rollback feature, so once you've deployed that's it.
There's a number of hand rolled strategies you could put in place, for example:
Limited Access e.g. Shared Hosting:
Where you don't have full access to the machine -
Backup the live site beforehand by downloading it.
Keep copies of what you deployed so you can push the previous version should something break
Full Access:
Maintain two sets of folders for the application and map your site to one or other of these folders. When you come to deploy switch the IIS site's physical path to the other folder then deploy. If the site fails then just knock the site back to the original folder. Each successful deploy would alternate between these two folders.
For stuff like user uploaded content you'd need to map virtual directories to a place on the file system that's always the same place because you don't want to be copying these around each time.
You're not the only one who has encountered these issues. Have a look at this article by Rob Conery and his observations about the state of affairs regarding ASP.NET deployment.
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
Using some form of Source Control would be another alternative. We use subversion, so if the publish goes bad, we can just update back to the last-good revision, and publish that. Even if you're the only developer, using source control can be very useful.