I have a web app (actually Orchard CMS) that I am customizing and I want to push directl from my build server to my hosting provider, using Web Publishing aka MSDeploy.
The problem is, when I publish the site (from Visual Studio, haven't tried it from the build server yet) it removes the write permission from the target web site, which makes Orchard instantly fall over because it can no longer access its database (etc).
We can debate the wisdom of this, but the bottom line is that Orchard requires write access, and web publishing insists on removing that access, which breaks the site. Not good. I have to log in to the service provider's control panel and reset the permissions each time I publish, which kind of makes the process less than automatic.
So, how do I get Web Publishing to leave the ACLs alone? I can't find any settings for this in the solution anywhere.
You can add turn off the ACL setting functionality by adding this to the .pubxml file:
<IncludeSetACLProviderOnDestination>False</IncludeSetACLProviderOnDestination>
See http://msdn.microsoft.com/en-us/library/ff398069.aspx
The article also mentions you can change this for all publish configurations via a local .wpp.targets file. Make sure to consider that option if you use multiple publish configurations
In some cases you may find that after publishing a project using Web Deploy the ASPNet IUSR cannot write to the root directory or any files within it (except App_Data).
By default Web Deploy sets the ACL of the ASPNet IUSR to read only. To prevent this from causing problems when you publish your application, you will need to locate the project file and make some changes. The project file will end with the extension .vbproj for applications written in Visual Basic or .csproj for applications written in C#. In the project file find:
<propertygroup condition=" '$(Configuration)|$(Platform)' ==
'Release|AnyCPU' "></propertygroup>
and change it to:
<propertygroup condition=" '$(Configuration)|$(Platform)' ==
'Release|AnyCPU' ">
<includesetaclproviderondestination>False</includesetaclproviderondestination>
</propertygroup>
This will ensure that ACL is not modified by Web Deploy.
If you already deployed to a 3rd party hosting provider, you may need to contact them to get your permissions reset before doing another deployment.
Related
I have published my IIS application to C:/inetpub/wwwroot/appDirectory and it's have different configuration in web.config file.
and in development version solution directory i have another web.config file and When i build solution my IIS start pointing to solution directory.
that's too annoying, every time i need to remove application from iis and again make application on IIS itself.
Go to properties of your web service in Visual Studio.
Navigate to Web tab
Either Change the local IIS to express or you can give a different application name so it wont replace your deployed application.
I get the following error:
Web deployment task failed. (Could not complete an operation with the specified provider ("appHostConfig") when connecting using the Web Management Service. This can occur if the server administrator has not authorized the user for this operation. appHostConfig http://go.microsoft.com/fwlink/?LinkId=178034 Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_NOT_AUTHORIZED_FOR_DEPLOYMENTPROVIDER.)
When I try to publish my project to Azure with "Configuration: Debug". If I use "Configuration: Release" there are no problems.
I have tried deleting and recreating the Azure website and re-installing the SDK.
I followed a tutorial to setup Azure so I think it is unlikely that I setup something wrong.
I've googled around and found people with a similar error however they don't seem to have a relation to the Debug/Release configuration...
It did worked!
But, just for making things easier, you can right-click in your project, and at properties, go to Package/Publish web and Unckeck the option
"Inculde IIS Settings as configured in IIS Express"
Remember (important!) you are in the right configuration (combo at the top) Release/Debug you are trying to publish.
I got the same error ERROR_USER_NOT_AUTHORIZED_FOR_DEPLOYMENTPROVIDER in VS2013 while deploying to Windows Azure Websites (WAWS) and nothing nowhere to find to fix it.
It just so appears that my project deploys just great again after comparing the project file with a brand new one and finding the following difference, which I commented out to get it working again:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<!--<IncludeIisSettings>true</IncludeIisSettings>-->
</PropertyGroup>
So, right click the project and click Unload Project, right click it again and click Edit project.csproj and find the PropertyGroup with the condition matching whatever you're trying to deploy (Release|AnyCPU in this case) and make sure that line is commented out.
I have tried multiple ways to get the production SharePoint content to my newly installed local development environment that is running on a VM Windows Server 2008 R2. After an export of the farm and a restore failed I came across this blog post and followed these instrucitons: http://richardstk.wordpress.com/2012/02/03/build-a-sharepoint-2010-development-test-environment/. To sum up, it's basically backing up the live SQL Content database as well as the Profile, Sync and Social databases, then restoring them on the dev machine and pointing SharePoint to use these new databases instead of the old ones. Then after that I deployed the custom webparts to the development server from within Visual Studio.
I've done this and it seemed to work pretty well. I can access Central Administrator as well as setting up a SharePoint Connection within Visual Studio and being able to see all the pages, lists, documents, etc. So it is definitely pointing to the new content database. I should mention I can also connect via SharePoint Designer and access all the correct content, Master Pages, lists, etc.
The problem I am having is that I am getting a "Could not load file or assembly" error when I go to the site in a browser and it takes me to /Pages/Home.aspx. The file is a custom webpart that I have deployed from within Visual Studio. When I look within the GAC I see the assembly listed but the PublicKeyToken is different from the one that is shown in the error message.
When I dig into it a little more I see that the custom user control is registered in my Master page, and when I look at the ascx file in the _controltemplates directory where it is located there is an Assembly that looks like this:
<%# Assembly Name="BlogRoll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=529e9730fe2a198d" %>
That PublicKeyToken is correct for the live site when I look in the GAC there but when I deployed it to my local GAC it created a new PblicKeyToken. Sorry if I'm rambling but I wasn't sure what was relevant and what wasn't.
I guess my question is how to handle this? It doesn't seem smart to change all the ascx files locally to match the new PublicKeyToken's that I have in the local GAC because then when I deploy these changes to live they won't find the appropriate assembly. What is the best way to handle this?
UPDATE
The code in question has a key.snk file that is being used to strongly sign it. My understanding is that this should make it so that it gets compiled with a specific PublicKeyToken each time and therefore install in the GAC with a specific PublicKeyToken. If that is true, then I believe the only reason it would have a different key token on my dev environment versus the production is that the key.snk file that has been provided is incorrect. Is that true?
You could use WSP Builder or WinGac to forcibly deploy the assembly with the correct PublicKeyToken to your local GAC.
Does MS Deploy support the following scenario?
Create a package from a Team Build drop
Install the web application into IIS6/7 including app pools, settings, etc.
It doesn't seem to want to let me configure IIS on the destination server if my package wasn't created from IIS originally.
If you pass the parameter DeployOnBuild set to true, then your build will produce not only your normal web site files under _PublishedWebSites, but also one whose name ends with _Package. That will contain your package, the parameters file and the manifest, plus a .cmd file for deploying the package.
What it will not contain is anything you didn't tell MSBUILD to place into the package. In particular, no, it won't contain IIS settings unless you told MSBUILD to place IIS settings there. It won't get the settings from out of the air - it will only get them from your local IIS, and only if that's where you have your project set up.
The current feature set does not support this scenario - Microsoft
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"