I have an asp.net application which uses some web services(WCF) in the solution exporer ( Through add reference). I can see that end points are defined in Web.config
Now i do not want to touch the web config in the production and i have two questions.
1. What dll should i be putting on production - Released one or debug dll.
2. Whatever is taken as reference (WCF) in our asp.net applicaiton. I hope only defining end point is sufficent assuming that i havent changed anything in the WCF Service.
I will appreciate if someone can guide in this regard.
Thanks in Advance- New to .net :(
Specific to your questions, here are the answers
1) On production servers "Release" build (dlls) is the best bet because they are optimized for performance. you don't need to add the reference again, unless there is some code change (which changes the wsdl of service)
2) End points will not be changed, therefore just by copy new service dlls, you should be good to go. The types in config file remain the same as in WCF service.
Check in your VSS for Configuration Manager,which one you are pointing it.It can be release or debug.
Whichever is choosen,you have deploy the corresponding one.WCF service,defining end point is fine.
Related
I don't think there is an answer to this one but I'm often wrong, so fingers-crossed I am this time too.
(1) In Visual Studio 2019 I have one Solution consisting of two Projects, both WebForms.
(2.1) Project1 stores book information (but that's not really relevant).
(2.2) Project2 logs to a database any exceptions caused by Project1. It has a single logFilter.aspx page, used to view those exceptions.
(3) I've added a reference to Project2 in Project1 but this isn't about sharing code, so that's not really an issue either.
(4) My question is, when I navigate to Project1 in a browser, is there any way I can access the logFilter.aspx page in Project2?
(5) Right now for example, I have to change the Solution's Properties to make both Projects "startup projects". Then I can access them both separately - in separate browser windows - like so:
(5.1) https://localhost:44340/bookPage.aspx (Project1)
(5.2) https://localhost:44389/logFilter.aspx (Project2)
(6) That works fine on my local machine during development. But I really don't see how it could work once I've deployed the lot to my web hosting company's IIS (at www.Project1.com for example) on the Internet.
(7) I could add the logFilter.aspx page to Project1. But then I would have different versions of it dotted around all my future projects.
(8) I've searched Microsoft Docs and StackOverflow but the few answers I've found seem to be MVC-related. This post does seems to provide an answer by adding a key to web.config like so:
<add key="WebsiteURL" value="http://localhost:2030/" />
and then using:
Response.Redirect(ConfigurationManager.AppSettings["WebsiteURL"] + "SRF-GeneralInfo.aspx");
I'm no expert but I'm assuming that I wouldn't have that Port information once I'd deployed it to a web hosting company's web server on the Internet.
The answer here suggests that you either make one project the child of another or that you use virtual folders on IIS which I doubt I would have access to.
Strange, as I would have thought this would have been quite a common practice for developers to want to do. Still, any thoughts anyone has would be most welcome.
Thanks in advance,
a setup that might work better is that you have a solution with two projects. Project1 is the webapp BUT PROJECT2 is a library.
Now when you get an exception on project1 you can call the class/function what you might need in project2 and log the information.
future projects (3,4,...etc) can still reference project2 for logging purposes.
I’m a fan of the new VS 2010 Web.config transformations. I use this feature for deployment purposes and wondered if it is possible to use them for debugging too.
I think of using them in the IDE: I want to create different built configuration (with linked transformation configurations); choose one of them; start the web site in the IDE and debug the different configurations this way.
Update
Thanks to a 3rd party plugin, SlowCheetah, this is now possible. Scot Hanselman has a blog post about it.
Original response:
Unfortunately, the web.config transformations appear to effect only publishing sites and building deployment packages.
In our scenario we have two development groups, one with access to multiple environments (in-house) and the other with access to a single environment (offshore). We have periods where the in-house group needs to debug directly against QA, while offshore remains locked-out (so their web.config's must point to the dev environment).
We were hoping to have 1x build-configuration per-environment, and be able to choose the build-configuration which matched the environment to debug against--which, as I understand it is your question.
In case anyone is curious why they haven't built this feature, from:
http://forums.asp.net/p/1532038/3711423.aspx
"When the web app gets run, the web.config under project root folder will be picked up by asp.net and I know unfortunately it is under source control . I certainly understand the cleanness coming with letting runtime use a transformed web.config from a temp folder; however, asp.net runtime doesn't know anything about vs projec structure and it is totaly based on directory structure. Using alternate path might also break as a web.config under a subfolder expect to inherit settings from the upper level of directory."
I found an alternative solution that does not involve any third party tool: http://ledtalks.blogspot.in/2011/09/webconfig-transformations-when.html. I only tried this for the web.config file
We have a series of web services that live in different environments (dev/qa/staging/production) that are accessed from a web application, a web site, and other services. There are a few different service areas as well. So for production, we have services on four different boxes.
We conquered the db connection string issue by checking the hostname in global.asax and setting some application wide settings based on that hostname. There is a config.xml that is in source control that list the various hostnames and what settings they should get.
However, we haven't found an elegant solution for web services. What we have done so far is add references to all the environments to the projects and add several using statements to the files that use the services. When we checkout the project, we uncomment the appropriate using statement for the environment we're in.
It looks something like this:
// Development
// using com.tracking-services.dev
// using com.upload-services.dev
// QA
// using com.tracking-services.qa
// using com.upload-services.qa
// Production
// using com.tracking-services.www
// using com.upload-services.www
Obviously as we use web services more and more this technique will get more and more burdensome.
I have considered putting the namespaces into web.config.dev, web.config.qa, etc and swapping them out on application start in global.asax. I don't think that will work because by the time global.asax is run the compilation is already done and the web.config changes won't have much effect.
Since the "best practices" include using web services for data access, I'm hoping this is not a unique problem and someone has already come up with a solution.
Or are we going about this whole thing wrong?
Edit:
These are asmx web services. There is no url referenced in the web.config that I can find.
Make one reference and use configuration to switch the target urls as appropriate. No reason to have separate proxies at all.
How can one specify the connection string in a config file of a class library and later modify this when used in a ASP.NET Web Application?
The Class library is a data access layer that has a Dataset connecting to a database based on a connection string specified in a config file (Settings.settings/app.config).
This class library is used in a web application where user inputs data and is written to the database using the DAL classes & methods exposed in the class library.
Now, I want to migrate this application from development environment to testing environment and later to production. The problem I'm facing is that after migrating to testing, the app in testing still connects to development database. I've changed the connection string mentioned in <class library>.dll.config file but this seems to have no impact.
Can someone explain the right way to achieve this? Thanks in advance for any help. Cheers.
With the .config files the name has to match the main executing assembly. For example I had a situation like yours, I needed a class library to have its settings in a .dll.config file. While it was able to reference it the actual application would not be able to read the config file because it was expecting .exe.config. Renaming the .dll.config to .exe.config fixed the problem.
In your case migrating your connection strings from .dll.config to web.config should fix your problem!
Good luck!
Joshua is partly right ... For posterity I would like to add a bit more to this answer as I have delt with the same problems on several occasions. First, one must consider their architecture. There are several issues you can run into with .config files in ASP.NET based on deployments.
Considering the architectural ramifications:
Single tier (one server):
A simple web application may be able to leverage a reference to the sites Web.config file and resolve your issues. This would be a fine solution for a single tier application. In the case of a windows application leveraged as a .exe file, the App.config will work too.
Multi-tier (more than one server):
Here is where things became a bit hairy for me the first time I was working with .config files across boundries. Remember the hierarchy of the config structure and keep this in mind (MSDN Article on .Config structure) - there is a machine.config at the root in the appropriate ASP.NET folder. These reside at each physical server. These are overridden by the site Web.config (or App.config) which are in turn overridden by subfolder .config files. If you have more than one .config file you may want to use one of the methods to pass the file path for the specific .config you want to use. More importantly, these files each may have connection information. ASP.NET's machine.config holds some for the framework ... so you should at least be senstive to the fact this is an "inheritance" chain. Second, any changes to the Web.config file once deployed will tell the application to restart. This will result in loss of state (bad if you have active users on the site). The way around this is to keep a separate .config file (e.g. connections.config) and put a reference to that file in the Web.config. This will allow you to change the connection information (e.g. password) without having to restart the application. Here is a link to more info: MSDN: Working with Configuration Files. This article lays out all the details you need to be aware of in a normal server / IIS deployed application. Keep in mind that the .config files are mainly intended for applications, not libraries. If you have several tiers, chances are you are using some communicaiton / messaging layer (e.g. WCF). This will have / allow its own Web.config. You can keep connection strings there (and encrypt them if needed), but better yet, put them in a second file referenced by the Web.config for manageability. One final point, if you are ever going to consider the cloud, .config files are wrapped for application deployments which in effect removes all of the benefits they offer in terms of "not having restart or redeploy". Azure deployments will want to consider this article to save themselves from nightmares of maintenance: Bill Lodin blog - Configuration files in Azul / Cloud. One other point on this article – great example on how to programmatically select configuration depending on deployment! Be sure to check that out if you want to add flexibility to deploy in or out of the cloud .
I hope these points saves all of you time and headaches. I know I lost a couple days of programming time dealing with these issues ... and it was hard to find all the reasons in one place why may app was not "implementing" its connection object. Hopefully this will save you all from the same fate I had.
I'm sure there's a simple explanation for this, but I haven't had much luck at finding the answer yet, so I figured I'd put the word out to my colleagues, as I'm sure some of you've run into this one before.
In my (simple) dev environment, I'm working with a handful of WCF Web Services, imported into my FB3 project and targeting a local instance of the ASP.NET development Web server. All good, no problems -- but what I'd like to know now is, What's the right way to deploy this project to test, staging and production environments? If my imported proxies all point, say, to http://localhost:1234/service.svc (from which their WSDLs were imported), and all I'm deploying is a compiled SWF, does Flex Builder expect me to "Manage Web Services > Delete", "> Add", recompile and release ever time I want to move my compiled Flex project from development to test, and to staging, and ultimately into production? Is there a simpler workflow for this?
Thanks in advance -- hope my question was clear.
Cheers,
Chris
If you have path names which will change depending on the enviroment then you will likely need to recompile for each environment since these will be compiled in the swf.
I typically use ANT scripts to handle my compile/deployment process when moving from development and production environments. This gives me the ability to dynamically change any path names during the compile. These build files can be integrated into Flex Builder making this process very easy once you have everything set up, and can be done with one click or scheduled.
Thanks Brett. I've been meaning to dig into automating my build processes anyway, so now's probably as good a time as any. :)
You do not need to build a SWF for each environment. Here's a technique I use commonly:
Externalize your configuration properties into an XML file; in this case, it could be a URL for each service or a base URL used by all your services
When the application starts up, make an HTTPService call to load the XML file, parse it, and store your properties onto some bindable "configuration object"
Bind the values from that object against your objects that depend on the URLs
Dispatch an event that indicates your configuration is complete. If you have some kind of singleton event dispatcher used by some components in your app, use that, so that the notification is global
Now proceed with the rest of the initialization of your application
It takes a little work to orchestrate your app such that certain parts won't initialize until steps 1-5 take place. However I think it's good practice to handle a lot of this initialization explicitly rather than in constructors or various initialize or creationComplete events for components. You may need to reinitialize things when a user logs out and a different user logs in; if you already have your app set up to that initialization is something you can control then reinitialization will not be a problem.