I'm finding conflicting information regarding the TFS 2010 Client assemblies. I wish to connect to a TFS 2010 server from an ASP.Net application running on IIS 7.5 in a 64-bit only application pool.
I x-copied all the TFS client assemblies into the bin folder of my web application (to avoid having to install the TFS client onto the web server) - but get a bad image format exception from the following assemblies:
Microsoft.TeamFoundation.WorkItemTracking.Client.Cache.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.dll
They all appear to be 32bit only assemblies.
Is there a way to work around this, or does the application pool have to be enabled for 32bit applications, before you can use the TFS 2010 client assemblies?
See my blog post on Installing Just the Server Components of TFS. That will let you get the 64-bit components you need onto your web server.
Related
I currently have a publish project from my local IIS which is windows 8 and already working but, my problem is I need to transfer it to our VM which is windows server 2008. I need some guidance or recommendation if I need to install Visual studio as well on the VM to publish it or is there any easy way that can simply copy the publish file from my local to VM windows server 2008.
You can publish from your project from local machine visual studio to remote server(in your case VM) if you have access to that server.
Alternatively manually publishing web project is just compiling in release mode with all dependencies & putting code in some IIS site/virtual directory with required Application pool settings.
Microsoft has very comprehensive documentation:
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/visual-studio-web-deployment/
I am developing an ASP.NET MVC 5 site targeting .NET 4.5.1 and for some reason I am struggling to deploy it on a Windows Server 2008 Standard edition server.
To be clear the site runs fine on my Windows 7 development machine and my Windows Server 2012 test environment but when I deploy it to the Windows Server 2008 in question I get this error:
At this point I tried all the advice about reinstalling ASP.NET and enabling runAllManagedModulesForAllRequests that I found in threads like this one ASP.NET MVC on IIS 7.5 but nothing would make it work.
Eventually I found that I could fix the problem by switching off the "Invoke only requests to ASP.NET applications or managed handlers" option for all managed modules in the application. What this did in essence was to make the following changes to the web.config file:
So my question is two-fold. Firstly, why is this change necessary to get the site to work? Secondly, am I safe to change the web.config permanently given that it will be installed on other servers as well, not all of which will be Windows Server 2008?
I have moved my asp.net mvc web application to our staging server and I have deploy it to IIS using visual Studio, as our staging server already contain Visual Studio .i did this bu right-click on my project and click on Publish. currently I need to move the asp.net mvc web application to production server and deploy it on IIS, but I have a couple of questions:-
Should I install visual studio inside my production server. Or it is better to avoid doing so ?
Is there a way to deploy my asp.net mvc directly to IIS , without uisng visual Studio ?
Thanks
Should I install visual studio inside my production server. Or it is better to avoid doing so ?
While you technically could, you shouldn't. There's no reason why you'd like to install visual studio on your production server since you'd only use VS to debug existing projects, however, your website should not be running in Debug Mode and it is a waste of resources to run a production website in Debug Mode. You should have your website pre-compiled and deployed in Release Mode. That said, an installation of VS will serve no purpose on a production server
Is there a way to deploy my asp.net mvc directly to IIS , without uisng visual Studio ?
Definitely, you can publish your pre-compiled website to a location in your hard-drive or even to a remote location and then manually copy the website files to your production server. That is the hard way. But, if you have Build management tool such as TeamCity integrated with source control system...then this task becomes even simpler since you can even publish projects automatically
1.bad idea. production server should have only your app code + advanced log system(nlog, etc) . nothing else.
2.
options:
xcopy deployment Compile your asp.net application and copy all the files to your server. You can do this by using FTP or shared directories. (Or anything else to transfer files.)
WebDeploy You have the possibility to deploy your asp.net webpage directly form your Visual Studio. If you go to "Build" and you choose "Publish Web". To be able to to do this you have to configure your server before. But this works automatically after you have set up everything. It's very handy since your deployment becomes easy to rebuild. http://weblogs.asp.net/scottgu/archive/2010/09/13/automating-deployment-with-microsoft-web-deploy.aspx
Web Setup - Installer Visual Studio provide also the option to build an installer. This works like installing usual software on your windows computer with the installer wizard. (See the link) http://weblogs.asp.net/scottgu/archive/2007/06/15/tip-trick-creating-packaged-asp-net-setup-programs-with-vs-2005.aspx
Manage multiple server There is also a way of managing the deployment of multiple servers. It seems to be a bit more complicated but could be interesting for professionals. (Check out on Google Microsoft Web Farm Framework 2.0
from here : Types of deployment in asp.net
Should I install visual studio inside my production server. Or it is
better to avoid doing so ?
Do not install VS on production servers. It is a bad practise.
Is there a way to deploy my asp.net mvc directly to IIS , without
uisng visual Studio ?
You can use your local Visual Studio to publish bits to remote IIS -
Automated Web Deploy using Visual Studio
Alternatively you can have new deployment strategies like let Team Foundation Server (TFS) deploy to IIS
One more option to is to FTP into Remote Web Server and push the latest bits from client side itself. I mean to ay, publish your site locally onto your file system. Then FTP into remote site using any FTP client like FileZilla. Then push the bits. For this to work, you need to configure remote server for FTP.
I have a TFS 2010 application installed on server1. I have the data tier on server2. We are going to get rid of the server1. I want to install the TFS application on Server2 (same server as data tier). First of all, which configuration option do I pick during the install? Do I have to bring my server1 down before installing application on the data tier server2?
You can find all the information you need at MSDN: http://msdn.microsoft.com/en-us/library/ms404879.aspx
I have been able to install 'VS2008 SP1' and 'VS2008 Tools for Silverlight' on my Windows Server 2008 development machine, but I have not been able to install the MSI for 'Silverlight Toolkit July 2009'. The install fails with the following:
"The system administrator has set policies to prevent this installation"
I am a local admin on the box. I have seen something similar when try to to 32-bit MSI on a 64-bit machine. Is that the problem that I am having?
I don't think that you need to install the SL toolkit on the server. At least, we haven't had to. We're using 64-bit Windows Server 2003, and any required Silverlight DLLs, etc., just get included in our .xap file, and get downloaded by the client when it downloads that file. All the server knows is that it's got to pass the .xap file down to a client when it requests it. The only thing that any server-side process might need to know about is the System.ServiceModel.PollingDuplex.dll (if you're using duplex WCF services), but if you simply install the SL 3.0 SDK on your dev machine, and then reference that DLL from your WCF project, it'll get included with your WCF project when you roll it out to the server in question.
The only reason you'd need to install those things on the server is if you're planning to do development on the server, which I suppose you might want to, but certainly isn't normal :-).