如何将我的VS 2012项目移动到Server 2003？没有实施源控制（即TFS）！ [英] How do I move my VS 2012 project to Server 2003? There is no Source Control (ie TFS) implemented!

问题描述

我在LOCAL Work计算机上的Visual Studio 2012中有以下内容：



- 包含3页，配置文件，一些图像的项目/解决方案

- 我还在项目中添加了AJAXToolkit

- 我在WEb.config上进行了一些小的调整，以便让AJAXToolkit和其他一些东西工作

- 我相信我使用的是.NET 4.0或.NET 4.5



我只能在我的本地执行/查看页面/ Web应用程序电脑。



我的问题是：



- 我怎样才能让其他人在工作时看看这个应用程序？我注意到我的URL，当我的页面被执行时，就像Localhost：xxxx / NameofPage.aspx我在WIndows 7

我尝试在不同的浏览器上键入确切的URL（同一本地计算机），但它不起作用



- 其次，最重要的是，如何将其移至Server 2003？我需要移动Bin文件夹吗？我需要发布它吗？我需要移动一个'包'（什么是包？）？我是否移动所有3个文件以及相应的web.config文件（如何移动我添加到项目中的ajaxtoolkit？）等？



最终，SHarepoint页面将指向此Web应用程序（Web应用程序将成为SHarepoint的Web部分）



如果有人能指出我正确的方向，我会很感激的！



谢谢!!!

I have the following in Visual Studio 2012 on my LOCAL Work computer:

- A project/Solution consisting of 3 pages, config files, a few images
- I also added the AJAXToolkit to the project
- I did a couple of minor tweaks on WEb.config in order to have AJAXToolkit and a couple of other things work
- I believe I am using either .NET 4.0 or .NET 4.5

I can only execute/view the pages/web application locally on my computer.

My questions are:

- How can I have anyone else at work look at this application? I noticed that my URL, when my page is being executed, is something like Localhost:xxxx/NameofPage.aspx I'm on WIndows 7
I tried typing the exact URL on a different browser (same Local computer), but it didn't work

- Second and most important, How can I move this to a Server 2003? Do I need to move a Bin folder? Do I need to publish it? Do I need to move a 'package' (what is a Package?)? Do I move all 3 files as well as the respective web.config file (How do I go about moving the ajaxtoolkit I added to the project?), etc.?

Ultimately, a SHarepoint page will be pointing to this web application (the web application will be a web part of SHarepoint)

If anyone could point me in the right direction, I'll be thankful!

Thank you!!!

推荐答案

目前尚不清楚它是什么意思，将其移至Serer 2003。这是什么？什么是移动？移动开发，部署应用程序，或者什么？



所以，让我问第一个问题。事情是这样的：没有一些 版本控制 系统进行开发是一种纯粹的疯狂。没有它，您的软件不属于您，它不属于您的公司，它属于每一分钟的灾难或错误。如果没有我专有权，而且，我会说，开源会好得多，只是因为你有价值的代码断言太重要了，不能把它交给没有完整源代码的东西。因此，它可以是免费的，非常轻便且非常可靠，它可以仅在服务器上工作或分发。你真的需要停止做你正在做的事情，并通过修订控制系统来解决问题。请查看我过去的答案：

制作一个不可点击的表格 [ ^ ] ，

需要wisesom的一些词来设置和/或使用服务器 [ ^ ];

和答案这个问题：修订控制系统，可供选择？ [ ^ ]。







我明白你的;我也面对这个问题，并且，在我工作的几家公司中，有一个令人无法接受的糟糕系统（一个例子是微软VSS：小心！一个大禁忌！）这些障碍不容易克服，但克服它们非常重要。公司还需要无人值守的自动批量构建，版本控制系统和其他必备项目。另请参阅乔尔测试： http://www.joelonsoftware.com/articles/fog0000000043.html [ ^ ]。



据我所知，Server 2003的问题是部署。我一开始并不清楚。这是另一个项目。我认为应该开发正式的，全面的一步批量无人值守部署程序。我可以像通过FTP（在Web世界中部署的最典型的访问方法）从开发系统的输出目录中复制（xcopy-type）内容一样简单。无论如何，没有什么太复杂了。在修订控制系统中，每个部署应该是一个承诺步骤，通常使用弱副本创建标签或分支，这将永久冻结（从而避免因分支而产生的合并问题）。



另外，我想警告你不要混淆3个程序：构建，修订控制更新/提交和部署。有些团队通过定义从版本控制和构建更新代码的过程来犯错误。例如，它们将修订控制过程添加为MSBuild项目中的构建步骤。真的行。但这个想法非常糟糕。开发人员需要进行大量的完全重建，原因有很多：尝试某种方式的实现变体或修复，做一些特殊的测试，还有更多。在大多数这些步骤中，不应涉及修订控制。



想象一下，每个操作都有一些批处理文件（这就是我所做的）。它们可以是：1）所有配置中的完整项目构建; 2）MSI发布版（适用于某些类型的产品）; 3）部署（用于其他类型的项目，如站点），4）某种清理，可选，5）更新产品的版本信息，可选。您可以拥有不同的配置，从而实现不同的批次。例如，您可以使用和不重新构建自动生成的文档来构建。每一步都应该是一次点击。但是，所有修订控制操作都应该由一个人根据人为决定分开执行。其中一些操作也可以是批次（取决于您使用的产品），但是...听一个好建议：不要将这些修订控制操作与上面提到的其他步骤混合。

-SA

It is not clear what does it mean, "move this to a Serer 2003". What "this"? What is "move"? Move development, or deploy application, or what?

So, let me ask just the first question. Here is the thing: it's a pure madness to do the development without some Revision Control system. Without it, your software does not belong you, it does not belong to your company, it belongs to every minute disaster or mistake. If does not have to me proprietary, moreover, I would say, open-source would by much better, just because your valuable code asserts are too important to hand it to something without full source code. So, it can be free of charge, very light-weight and very reliable, it can work on a server only or be distributed. You really need to stop doing what you are doing, and settle yourself with a revision control system. Please see my past answers:
Make an unclickable form[^],
Needs some words of wisedom to set up and/or use a server[^];
and the answers to this question: Revision control systems, which to choose from?[^].



I understand you; I faced with this, too, and, at couple of the companies I worked in, there was unacceptably bad system (one example is Microsoft VSS: beware! a big no-no!) Such barriers are not easy to overcome, but overcoming them is very important. A company also need to have unattended automated batch build, system of versioning, and other must-have items. See also the "The Joel Test": http://www.joelonsoftware.com/articles/fog0000000043.html[^].

As I understand, your problem with "Server 2003" is deployment. It wasn't clear to me in first place. This is is another item. I believe the formal, comprehensive one-step batch unattended deployment procedure should be developed. I could be as simple as copying ("xcopy"-type) the content from an output directory of the development system through FTP (most typical access method for deployment in the Web world). Nothing too complex, anyway. In revision control systems, each deployment should be a single commitment step, typically creation of a "tag" or "branch" using "weak copy", which is frozen forever (thus avoiding the merging issues which stem from branching).

Also, I want to warn you against mixing up 3 procedures: built, revision control update/commit and deployment. Some teams make a mistake by defining the the procedures of updating code from revision control and build. They, for example, add revision control procedures as a build step in a MSBuild project. It really works. But the idea is really bad. Developers need to make a lot of full rebuilds by many reasons: trying out some way of variant of implementation or a fix, do some special testing, and a lot more. In most of these steps, revision control should not be involved.

Imagine you have some batch files for each operation (this is what I do). They can be: 1) full project build in all configurations; 2) MSI release build (for some types of the products); 3) deployment (for other types of projects, such as sites), 4) some kind of clean-up, optional, 5) update of the version information of the product, optional. You can have different configurations and thus different batches. For example, you can have build with and without th re-build of auto-generated documentation. Each step should be one click. But all the revision control operations should be separate and performed by a person, based on a human decision. Some of those operations also can be batches (it depends on the product you use), but… Listen to a good advice: don't mix those revision control operations with other steps mentioned above.

—SA

这篇关于如何将我的VS 2012项目移动到Server 2003？没有实施源控制（即TFS）！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！