I have developed a feature using sharepont 2010, feature Scope is "Web", feature Deployment Target is "WebApplication"(Deployement Target has been set throw Package->Advanced->Add->Add Assembly from Project Output->Deployment Target as "WebApplication).
In this feature using "SPWebConfigModification" class updating web.config file.
My concern is below:
1)After deploying it should go to particular "web" since its a "WebApplication" deployemnt but this feature is availabe in all the web apllication in the server, even though if we go to Central Admin->System Setting->Manage Farm solution, we can see this .wsp file has been deployed to particular web application not Globally Deployed. I think this looks strange. My requirement is, the feature should be available in one web application not in all web application. Can somebody point me out pls whats wrong in this or how can we do this?
This has to do with the property ActivateOnDefault in the feature manifest file, this property ONLY applies to features scoped at Farm and Web Application levels. Any feature (Farm or WebApplication) with that setting set to True will automatically activate on all web applications when you deploy the WSP solution. This property is set to true by default.
Read more about it here:
http://www.sharepoint.bg/radi/post/Activate-on-Default-confusion-and-features-scoped-at-Web-Application-level.aspx
Related
I am trying to use maven profiles and filtering in order to produce two different versions of a given web archive (war):
A first one for local deployment to my local machine on localhost
A second one for remote deployment to cloudfoundry
There are a number of properties that differ according to whether the app is deployed to my local machine or to cloudfoundry.
Of course the difficult bit is that I am trying to do all this from STS/Eclipse and deploy from Eclipse to my local tomcat and to cloudfoundry...
Can anyone please provide advice, tips or suggestions?
If you are using Spring versioning 3.1+ the "profile" attribute for <beans> in the spring bean configuration xml would be the best choice. Take a look at the doc here: http://docs.cloudfoundry.com/frameworks/java/spring/spring.html#using-spring-profiles-to-conditionalize-cloud-foundry-configuration
Basically you need to specify at least 2 elements. One for your local properties (profile="default") and one for the properties when deployed to CF. The latter one should be defined as <beans profile="cloud">. When running locally the properties within "cloud" would be ignored and properties in "default" will take effect. When pushed to CF, CF will detect the profile named "cloud" and, which is better, inject corresponding datasource connection info of the services provisioned by CF itself. You can find the detailed CF-specified properties in that doc as well.
For more information about the profile attribute, see the doc here: http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/
Consider having a single project per artifact generated. Hence one project generating your local deployment and one project generating your cloudfoundry deployment.
Overlays (http://maven.apache.org/plugins/maven-war-plugin/overlays.html) is the officially sanctioned way to bake in extra files in an existing WAR file, giving a new WAR artifact. Very useful but may be too slow for comfort while developing.
I am using Web.Config transformations to deploy my application to Azure. I also have 2 sites in my service, a public website, and private WCF site endpoint. I am deploying multiple sites to a single role.
When I deploy, the website project (for which the Azure Deploy project is set) transforms the web.config correctly. However, the WCF project (which is only addressed as a "site" in the .csdef file) does not transform the web.debug.config file to web.config.
This question is similar, but only addresses the projects building. I have set the dependencies in my project.
This workaround forces the transform of the web.config file, but it still does not appear in my deployment on Azure.
I suspect that this bug still exists, and I have also upgraded to the Azure 1.5 SDK in hopes that it will fix it.
I would like to try putting my configuration data in cscfg files but I am using Entity Framework Code First, and I do not know how to get my connection string to work with this format. EFCF seems to rely on web.config explicitly.
Any help would be appreciated.
When you add another web role, you provide a physicalPath to point to what you want deployed, and all the SDK does is copy the files it finds at that path into your package. It doesn't do a build.
You should probably be doing a build and a publish of the web app you want to deploy, and then point the physicalDirectory at the output of that publish step. (Make sure the directory you're setting in physicalDirectory contains exactly what you want to have deployed to the cloud.)
I have a Azure project (Azure 1.3) in VS2010. There are 2 webroles, one web page project and one WCF project. In debug mode I want the web project to use a web.config for DEV enviroment, and when publishing the web.config for PROD must be used.
What is the best way to do this ?
Currently I am facing issues when using a Web.Debug.config with transform XSLT. It doesn't seem to work in Azure....
Solve your problem a different way. Think about the web.config always being static and never changing when working with Azure. What does change is your ServiceConfiguration.cscfg.
What we have done is created our own configuration provider that first checks the ServiceConfiguration.cscfg and then falls back to the web.config if the setting/connection string is't there. This allows us to run servers in IIS/WCF directly during development and then to have different settings when deployed to Azure. There are some circumstances where you have to use web.config (yes, I'm referring to WCF here) and in those cases you have to write code and create convention instead of storing everything in web.config. I have a blog post where I show an example of how I did this when dealing with WIF (Windows Identity Foundation) and Azure.
I agree with Mose, excellent question!
Visual Studio 2010 includes a solution for this type of problem, web.config transforms. If you look at your web role you'll notice it includes Web.Debug.config and Web.Release.config along with the traditional web.config. These files are used to transform the web.config during deployment.
The canonical example is "I need different database connection strings for development and release" but it also fits your situation.
There is an excellent blog post from the Visual Web Developer Team that explains how to use this feature (don't bother with the MSDN docs, I know how it works and still don't understand the docs). Check out http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
I like this question !
For worker roles, I solved this problem by detecting the environment at runtime and launching my 'application' in a new AppDomain with a custom configuration :
bot.cloud.config
bot.dev.config
bot.win.config
This is incredibly efficient !
I'd like to do the same with web projects, because using the Azure specific configuration is a lot of trouble :
Both config are not in the same place, which is time-consuming when debugging
You have to learn a new way of writing something that sould be standard
Sometime you'll wonder if the app falled back on web.config because of a stupid syntax error
I'm still searching the right way to do that, like in this post
Another possible solution is to have two CloudService projects, each one with specific ServiceConfiguration.cscfg(dev/prod). Develop using the Dev, but deploy the Prod.
Currently I am facing issues when using a Web.Debug.config with
transform XSLT. It doesn't seem to work in Azure....
It depends on whether you want to make it work on your local machine or inside continuous integration.
For the local machine I tried to answer here: https://stackoverflow.com/a/9393533/182371
For the continuous integration it's even easier. When you build from the command line specifying the Configuration property value your configs WILL be transformed (no matter what it does when you build inside VS). So properly specifying build configurations for both cloud and web project will give you the correct output depending on build parameters.
We were using JDev to develop our applications and deploy them to OC4J and OAS.
we used to use JDev to create the data-source configuration for us both on dev and on deployment. (on dev using the wizard that come with jdev to connect to data-source.. and on deployment hence we don't need to do any Data-source configurations on the app server manually)
But, when we moved to eclipse, we couldn't no longer be able to deploy the EAR file unless we create the data-source manually (either using the em or j2ee\home\config\data-sources.xml but on some deployment, we may not be able to do such thing.
So, can we add some files for example to the EAR so that we can tell OAS that we need from it to create the DS for us??
Hint (I am hearing about some thing named orion*.xml, is this related to that request??
Thanks.
You can.
You need to place the correct data-sources.xml into your EAR/META-INF and reference it from your EAR/META-INF/orion-application.xml the same way as j2ee\home\config\data-sources.xml is referenced from j2ee\home\config\application.xml
We have recently added some functionality to our web site that requires adding a service reference to an api in an external domain. Adding the reference to a VS2008 project createed a sub-folder in the "Service References" folder and added 18 files to that folder that appear to represent the classes in the api. The api provider also had me add custom binding and client references to system.serviceModel in my web.config file.
Do I have to deploy that entire folder with its 18 files to my production site to use the web service? Does some of it get compiled into my project dll? I can find all kinds of references to deploying a service, but not what is necessary to deploy a service consumption module.
Sorry for short, but I don't have the answer for you. But you can get this answer yourself. This is the only way Iwould get the answer. Deploy it without them, see if it works. If it doesn't deploy with. If it works, then you know.
The good news is that I have to deploy absolutely no files from the project have to be deployed to the production site. Everything the web service consumer application needs gets compiled into the application assembly.