Before we used TFS, we were building our packages locally using visual studio. There was a lot of projects organized into solutions. When we wanted to build the package, we simply located the ccproj project, right click on it and hit “package”.
There is couple of specific in our solution:
We use web roles with multiple web sites and virtual applications and we have them as project dependencies in VS2012 solution
We use config transformations for both web and worker roles. Worker roles transforms was achieved by adding transform target manually to the project file.
We have some additional class library projects – their outputs needs to go in a subfolder of the worker role along with correct configuration files, it is kind of plug-in architecture. We used some xcopy commands to include these non-referenced libraries in our worker roles.
Everything worked smoothly when building in VS 2012 locally.
When migrated to TFS we quickly learned that we won’t be able to replicate the same build process on build server
It turned out that TFS is not preserving solutions structure, more
details here:
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/9ac815c8-5961-4670-a6d0-660a9b66da9c
The project dependency that was solving multiple web sites and
virtual applications in a single role did not work on build server,
probably because of different output directory. We had to add some
hacks in our ccproj and csproj files to get these published and
correctly included in the resulting package.
xcopy commands failed because of different directory structures on
TFS build sever.
We had to force run cspack on TFS build server by explicitly adding
/t:Publish parameter to msbuild command line.
Config transforms for worker roles did not worked, we had to force to
occur using another hacks in the ccproj and csporj files.
There was more issues but those are too detailed. I would keep it on
high level just to illustrate the whole issue. The build somehow
works now, but we have now a lot of hacks in place now.
I have two questions:
Is it possible to configure TFS build server to have exact same
behavior as the local build in VS2012?
Is there any official solution for building azure packages with multiple web sites and virtual applications in a single web role?
I haven't yet tried this on a TFS build server, but the approach outlined in my blog at http://michaelcollier.wordpress.com/2013/01/14/multiple-sites-in-a-web-role/ has been working well. The "trick" is basically to modify the .ccproj file to tap into the CoreBuildDependsOn target, adding logic that will execute MSBuild against the secondary sites. This should also allow config transforms to work.
Related
I have a solution in Visual Studio Team Services that has 2 Web Applications (specifically one project for WebAPI services and another for the actual site using MVC).
I'm trying to set up continuous delivery to Azure but all the information that I can find seems to assume that you only have a single Web Application within your solution (which seems a little unrealistic for all but the simplest of projects!).
The out of box continuous delivery process seems to just pick and deploy the first Web Application it finds (which isn't necessarily the same project each time!)
I've tried specifying the Deployment Settings file, but that seems to affect the destination rather than the project being deployed since again, it seems to just "pick" a project to deploy, and each time it deploys every single compiled assembly plus all dependencies rather than just the binaries and dependencies of the project actually being deployed, which can cause issues with MVC finding duplicate controller matches for a given name (this can of course be fixed by specifying the namespace of the controllers within the route configuration, but that seems less than ideal, and still doesn't fix the entire problem).
Ideally I'd like to find a way to deploy both projects with a single build, but as a temporary solution I'd be happy with 2 builds that are both triggered by a check-in of the single solution, that each reliably deploy 1 of the 2 Web Applications.
Does anyone know if this is possible? I guess I could write my own custom build template, but I'm hoping there is an easier answer (not least because I can't imagine that this isn't a problem being faced by other people!)
I did find this question TFSPreview.com and Azure continuous deployment for multiple solutions in TFS but since that's quite old and is specifically talking about AzureWebRoleProjects rather than Web Applications being deployed to the newer Azure Websites feature, I'm hoping that there is a more positive answer?
This is possible with multiple build configurations. In addition to Debug and Release you could specify two more, one for each app.
You can find these in Visual Studio at Build -> Configuration Manager. And then in the configurations specify only one of them to be built. Then running MSBuild with that configuration will output only one WebDeploy package.
We're trying to figure out how to automate our website deployment. We've picked an existing project, and started playing around.
First, I used the Publish wizard from with VS2012 to create a Web Deploy Package. We then tried deploying the package as a website, through the IIS Manager, and that succeeded without a problem. We thought we were nearly there.
What was next was to learn how to run this from the command-line, so we could script it. And that's caused us no end of headaches.
We've been playing around with msdeploy.exe, and with the .cmd file that the publish wizard created, and while both methods seem to install the package as a virtual directory just fine, neither will install the package as a root website.
Browsing around on the web, I've run across this:
Web Deploy iisApp Provider
In a sync operation, the iisApp provider copies content to a folder under the destination site that you designate and marks the destination folder as an application. The iisApp provider cannot create a site. The iisApp provider will not create applications under sites that do not exist.
And
If you want to synchronize a Web site and its related configuration, use the appHostConfig provider.
At this point, we don't know beans about iisApp, or appHostConfig, or whatever. We didn't create a package that used one or the other, VS2012 did. We haven't a clue, at this point, how to convince VS2012's web publish to create an appHostConfig package, and for that matter, I don't know if we want to.
Here's the thing - whether a given website is installed as a root application or as a virtual directory is not something the developers control - it's a decision made by the implementation team. Or testing team usually installs any given website both ways, to ensure that both work.
And since IIS seems to be able to manage to install this package as a root site, there must be a way to get msdeploy to do it.
But how?
I created a wsp solution that which create 2 custom workflow actions. I want to deploy it to my 2 servers farm which have an application server and a webfront end server. SPF Web application is not activated on the app server.
My visual studio solution goes like this:
-One project which create the dll, where actions code is.
-One project which create the wsp package, feature, etc. The package references the other project as additional assembly.
My problem is, when I deploy my wsp package with Deployment Server Type WebFrontEnd, the feature is only installed on the wfe and I can't activate it. I can't see the feature in the manage feature page (the feature is farm level). When I change the Deployment Server Type of the package to ApplicationServer, I get the following message:
"This solution must be deployed to application servers, not front-end Web servers. It cannot contain a resource that is scoped to a Web application."
I did some tests. I removed the additional assembly from my package and then I can deploy my wsp solution as ApplicationServer type (but can't use my custom actions..). Then I created a dummy dll with nothing in it, added it as additional assembly to my sharepoint package and I realised I can't deploy my wsp as ApplicationServer type again.
So, can I reference an additional assembly from my wsp solution and still deploy as ApplicationServer type??
How can I deal with this? Any idea?
I did it again, I've been looking for answers for this all day, I finally post something here and one hour later, I got myself the answer. Here it is anyway.
I deployed independently both solutions using 2 wsp packages. One simply deploys the dll into the gac (and is ApplicationServer), the other one is using it without deploying it itself (and is WebFronEndServer). Now I have to deal with making sure the first one is deployed before using the other one... Feature activation dependency should do it.
Regards.
I've got a TFS build set up to build and deploy a web application. I'm passing in the MSDeploy parameters via the TFS build definition's MSBuild arguments. First time round this is working fine. When someone accesses the web app, one of the controls (Microsoft charting control) generates a couple of files in an empty directory I've added to the solution.
When I go to rebuild (or continuous integration is triggered) the next build will usually fail because it can't delete one of the generated files. When I try and manually delete the file it tells me that IIS worker process is using it and it can't be deleted.
Now to get the build building I'd have to manually restart IIS every time, which is not desirable with CI in mind. I've taken a look through Microsoft.Web.Publishing.Tasks.dll and there's nothing there to restart IIS using MSDeploy.
At the moment I'm thinking that adding stubs of the temporary files in the solution might be a resolution (maybe MSDeploy will be able to close the process if the file is a permanent part of the deployment) or I could do some unpleasantness with Exec in the solution file to get an IIS reset.
It's probably a long shot but has anyone come up against this and found a nice solution?
You could use MSBuild Extension Pack to stop the application pool automatically before deployment. There are several tasks in the MSBuild.ExtensionPack.Web namespace to manage IIS, such as stopping and starting an application pool, deleting an application, etc.
I’ve inherited a SharePoint solution where all the projects have strong names and are deployed to the GAC.
I find that its difficult working with projects that are signed, it slows down development, testing and makes debugging difficult.
So, is it possible that SharePoint projects, WebParts, Codebehinds etc be deployed to the local bin instead of the GAC? Is it considered bad practice to deploy to the local bin?
It is always recommanded to use the Bin directory over to GAC, for all the WebParts & Code Behinds. As that will restrict the Trust given to the code, GAC provides full trust to the code.
After deploying to the bin you can gain the required permission using CAS.
I recommend you to read the chapter Application Security of Inside Windows SharePoint Services 3.0 Book
Note: You will have to deploy your code Feature Handler, Timer Job etc to the GAC
By default, SharePoint Web applications are only allowed to run with a very restrictive trust level of WSS_Minimal. If we want to have our Web Part deployed to the bin folder, then in order for it to run we must do one of two things: either set the trust level to WSS_Medium or WSS_Full in the web.config, or create a custom CAS policy that will allow this assembly's managed code to run. In a production environment, you will need to make an informed decision on this yourself.
I would use the GAC for local development and testing and use the bin in production.
To debug locally, check the following in your config file:
customErrors=off
Enable Stack Traces by adding CallStack=”true” to the SafeMode tag
Set the compilation debug attribute to "true"