ClickOnce::Deploy Windows-based applications to a Web server

It seems that the developers are deploying manually (Copy & Paste components to virtual directory) to run the windows application from web browser. They doing building, moving the all bin files to virtual directory when ever application is updated.

This process generally has the security limitations and hard to manage. I just want to share and suggest there is a known easy way to deploy the windows application to web server and run the file from user’s machine. Visual Studio 3.5 provides the Click Once deployment which replaces all this process.

ClickOnce deployment allows you to publish Windows-based applications to a Web server or network file share for simplified installation. It provides full support for publishing and updating applications deployed with ClickOnce.

ClickOnce can provide automatic application updates. A ClickOnce application periodically reads its deployment manifest file to see if updates to the application are available. If available, the new version of the application is downloaded and run. For efficiency, only those files that have changed are downloaded.

So instead of doing the manual deployment it is easy to use this process which reduces the manageability. I suggest using this, helps through out the time till the application expires.

Teamprise Client Suite

Teamprise Client Suite currently includes the following:

Teamprise Plug-in for Eclipse: Allows developers to perform all their source control, bug tracking, build and reporting operations from within Eclipse

Teamprise Explorer: Combines all the functionality available to Eclipse developers using the Teamprise Plug-in into a stand-alone, cross-platform graphical user interface (GUI) application

Teamprise Command-Line Client: This provides a cross-platform, non-graphical interface to Team Foundation Server, making it perfect for scripting and build scenarios or for developers who prefer a command-line interface

Team Foundation Server for Java Applications with in Eclipse

As I am promoting the Team Foundation server across the teams, during our last two demonstrations with project teams, a question that how Java Applications can use the Team Foundation Server which are running on non windows operating systems such as Linux, Max OS X.

Here is the Solution:

Java applications are typically developed and deployed in multiple environments and platforms work under Eclipse IDE uses below Configuration Tools.

1. Java Configuration Tool- JFig
2. Sub version
3. Concurrent Version Systems- CVS
4. IBM- Configuration Management Version Console- CMVC

But Microsoft Team Foundation server doesn’t run under non windows operating systems cannot support java applications. So to use TFS features efficiently, Microsoft provides the “Teamprise tool” costs $499 per user or with discounted volume licenses.

Teamprise is a suite of client applications for accessing Microsoft Visual Studio Team Foundation Server from outside the Visual Studio Integrated Development Environment (IDE). Teamprise enables development teams to use the source control, bug tracking, work item tracking, build, and reporting features of Team Foundation Server from within the Eclipse IDE, and from other operating systems, including Linux and Mac OS X.

Once we install “Teamprise Plug-in for Eclipse”, it allows us to satisfy the needs of developers working in .NET and those working in Java on Linux desktops can perform all TFS operations.


References:
http://www.teamprise.com/products
http://www.teamprise.com/news/2007/05/teamprise_announces_java_sdk_f.html
http://www.woodwardweb.com/2009/10/

Not getting Latest version - TFS

When two developers are working on same file which is checked out by both, so whenever one changes something and check in source, the new source has to be used. When one check out the source edited by other developer, first developer were getting the same version as the second have but not the latest source. So every time when you do the Get Latest Version you don’t get the latest source and you'll be prompted with the resolve conflicts dialog.

Let me explain the reasoning behind it. When you perform a get latest version operation to populate your workspace with a set of files, you are setting yourself up with a consistent snapshot from source control. Typically, the configuration of source on your system represents a point in time snapshot of files from the repository that is known to work together, and therefore is buildable and testable.

As a developer you working in a workspace, you are isolated from the changes being made by other developers. Ideally when you do this, you'll update the entire configuration of source, and not just one or two files. Why? Because changes in one file typically depend on corresponding changes to other files and you need to ensure that you've still got a consistent snapshot of source that is buildable and testable.

This is why the checkout operation doesn't perform a get latest on the files being checked out. Updating that one file being checked out would violate the snapshot and could result in a non buildable and testable.

As an best practice, Team Foundation forces users to perform the get latest operation at some point before them check in their changes. That's why if you attempt to check in your changes, and you don't have the latest copy, you'll be prompted with the resolve conflicts dialog.

And one more thing as I already told you that you not to use of "Get Latest from Solution Explorer" because it is far slower and less reliable than doing it from the Source Control Explorer. Solution explorer has to crawl your whole project structure and issue non-recursive calls, but Source Control window requires no parsing and issues one single recursive web service call.