We are updating an ASP.NET Web Site project that uses ADFS 2.0 Authentication to use the one click "Publish Web Site" deployment process. We currently have three different FederationMetadata.xml files for each environment (dev, test, prod). How do we publish these files to each environment?
We use the web config transformation files for the web.config file. But I do not believe this can be used for xml files? From the searches that I have done I found two possible responses to this, neither seem very good. First one says to delete the FederationMetadata file and manually configure ADFS 2.0 (How do I change my WCF's FederationMetadata.xml file for various deployments?). We could do this but it seems like a step backwards. The second involves creating a dummy FederationMetadata file and populating it in the global.asax.cs file. (How to deploy asp.net web application to development team via TFS when setting up ADFS authentication). This approach seems very hackish and hardly the recommended approach.
Is there a recommended approach for this? Is there something obvious that I am not seeing? Any thoughts on this would be much appreciated!
If you indeed did manage to get the web.config correct then you can generate the metadata on the fly (per request). Same code for all environments. No need for the static file.
In telegram style just for the class names: For a Forms ASP.NET application it would be an HttpHandler (for MVC a controller). In the handler you must build a ApplicationServiceDescriptor, and use a MetadataSerializer to spit out the XML. Fill it with the info from FederatedAuthentication.WSFederationAuthenticationModule (which has obtained it from web.config).
Related
We are developing intranet base solution in ASP.NET MVC. It will be deployed across client's own internal network hence respective employee of client can use it.
As it is IIS based intranet application, one can easily copy files and configure IIS on other server. So what are the different solution available to prevent this.
Thank you in advance.
Generally when you are publishing the ASP.NET MVC web app, you can publish the version in dlls.
So Instead of creating a single Web App, you can create a new dll file where you are going to compile all the Models of the App and save it in a dll).
Then coming back to your original solution you will add the reference to this dll so no logic can be taken of your solution.
Q:
Recently , i face some problems, i have a dll common among a lot of applications,and any change to this dll require to build it, copy and paste it in each bin folder of these applications ,and add the new reference so i decided to convert this dll to a web service in stead to overcome this overload..
I make a web service application contains set of web services(mapping to each class).
I face some problems here:
In the original dll, there are
classes use methods exist in other
classes in the same dll, and i face problems when i
tried to use web service methods in
other web service class.how to fix
this problem.
In the original dll there are set of
static classes with static
methods.how to make the equivalent in
my web service application.
Any overload method cause a problem
in my web service.
When using Dictionary<string, string>
as a parameter in my method.
Note:the original dll contains the connections to the data base. Is converting it to web service is the optimum solution?which one is faster in my case a web service or the dll?Should i tend to WCF instead of?
thanks in advance.
In my applications I usually have all related projects in the same solution. But when I need to use projects across applications I replace the project for a dll reference.
Because I use Subversion I solve the problem of copying the dll by adding an external property do my libs folder, referencing the build of the dll.
If the external dll is updated very often than you probably need a continuous integration system to handle that for you.
I usually add project reference and keep all my projects under single solution, so I do not have file copy issue. You might be missing project reference, instead you could have used assembly reference. Verify that first.
First advice, don't create a web service if you don't know what it is and how it can be used. People tend to think everything is a web service since creating a web service in WCF is so easy by using visual studio tools. Since you ask like converting DLL to a web service, I assume that you are beginning with learning web service.
All you need is kind of continues integration system otherwise a simple build system which does the build for you and it copies the files wherever depended applications folder. Hence you can save your time for coping files manually. When you do this, you will not have any of those 4 problems you have mentioned.
If you are lazy enough to learn the build system, simply write a batch file that would copy the files for you. I do have batch files which does xcopy files.
Currently we have a bunch of web sites (web site projects) that I think should be converted to web application projects. Everybody agrees.
But a number of custom BuildProviders are used to generate controls and unfortunately MSDN says that
Adding a customized BuildProvider class to the Web.config file works in an ASP.NET Web site but does not work in an ASP.NET Web application project
Are there some ways to migrate though without full discarding of custom BuildProviders mechanism?
Without knowing exactly what your build provider do I can see two possible solutions:
Custom MSBuild tasks
T4 templates
Hey you need to implement, a custom IVsSingleFileGenerator.
And register it with your VS, to generate a custom .designer-File.
The way DesignTime-Compilation works changed with Web Application Projects.
In combination with a BuildProvider you will get the same as ASPX-Pages.
I used it to generate user-interfaces with partial-methods to implement behavior in a codebehind-file.
That's impossible without review of the whole approach.
I'm working on building a set of ASP.NET (2.0) web-services to be deployed into a single web application under IIS7. The services will be added incrementally (over a period of a year or more) by multiple programmers. How should I organize my source in VS2005.
Should I use one project or several?
Should I use a Web-Application or Web-Site project.
How do I manage the web.config that they will all share.
Thanks for your advice.
Do you use source control now? All of your "control" problems are solved by any decent source control system (i.e., not VSS).
I'd put them into a single project assuming they have code and types in common between them. For instance, if they use the same data access layer and underlying database.
I would never use web site "projects" for web services. Any of their advantages are advantages for web sites made up of web pages, and not for the more complex requirements of web services.
I'll speak to how our shop handles this, which I find to work well.
We use several projects. One for each web service. This allows us to publish one service without effecting the others. We're also on VSS (bleck!) which makes for less conflicts.
We use a Web-Site project and it works fine
We manage the web.config by doing a diff on the file before we publish. The web.config's are something that rarely change
Is there any difference between website and web application project? What if you are working on a project that is sort of hybrid of site and application? which project should you chose?
I'ld go the newer Web Application project (always, regardless of the size of the project).
There is nothing to lose and everything to gain with using the Web Application Project (you cannot say this about using the "website" only).
The official list of differences are here:
Use Web Application Projects when you
Need to migrate large Visual Studio.NET 2003 applications
Need to
control names of output assemblies
Need stand-alone classes to
reference page and user control
classes
Need to build a Web
application using multiple Web
projects
Need to add pre-build and
post-build steps during compilation
Use Websites if you:
Need to generate one assembly for each page.
Prefer single-page code model to code-behind model.
Prefer dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).
Want to open and edit any directory as a Web project without creating a project file
#Mehrdad's link here is essential if you want to know more http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
As for which project to choose, I would go with the Web Application Project, regardless of size. Having all of your code behind compile down into a single DLL is a major benefit for maintenance and security on the hosting end. I know there are precompile options for web site projects, but they seemed like more trouble that it was worth for me.
I know that the IIS filters are in place to prevent users from accessing your .vb or .cs files, but it still makes me a little leery.
But more important to this is the nice fact that if you make a bunch of coding changes, or maybe add some classes and change the processing logic, the only thing you have to merge up is the compiled DLL and nothing else. Similarly, if you do a few UI changes (say change the stylesheet or position of a few controls), you don't have to worry about recompiling the application, you simply bring over the update .aspx page and you're done.
Take a look:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
http://forums.asp.net/p/1300026/2538628.aspx
I'm used to create websites when I want to create a new webapplication.
My current project had some problems on compiling, so I switched to a webapplication project. The step isn't very hard. Visual Studio helps you to change all necessary lines.
Refer to the links in the post:
http://www.codersbarn.com/post/2008/06/01/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Anthony :-)