We are using VS 2012 with TFS 2012.
We want to prevent some users to view particular source files in a project,
We know how do this,Actually by right clicking on the files on the source control window and manage permissions in security tab.
The problem is that when we prevent a user to view or change a file such as HomeController.cs
the user can't build the project and the vs IDE says that the file does not exist,
How we prevent access a file with the ability of successful building project for the user
If you prevent read / view permission then how can the compiler access the file in order to build it? If the compiler can see the file then so can the user.
Are you sure that you want to prevent these users from even seeing the file, or do you just want to prevent them from changing the files? If it's the latter then you can simply remove the permission to check-in.
There is another avenue that may be of use in your situation. Split the project up into libraries and only combine all the libraries on the build server.
The developer can build but not run on their machine. With gated check-ins the build is made available.
This works especially well if the project is web based and the build server deploys the assemblies to a web server that the developer can view.
Otherwise the notes on obfuscation and decompiling stand.
Related
I have a Basic MSI Project in InstallShield 2012 Spring. This project installs sample documents to the current user's Documents folder (Not the Public Documents folder). When I then log onto another user, I see the application installed, but I do not see those sample documents in the second user's Documents folder (this makes sense). My question is, is there a setting in InstallShield or a way to have the sample documents install for this second user when the second user launches the application? Can launching the application detect that there are files missing in the user's Documents folder and then trigger a repair?
While this is possible, I would not recommend it. The user should control what goes in his or her documents folder; the large number of applications out there that do not respect this is not a good reason for another not to do so. Instead the application should have a way to browse the samples, open them as templates, etc., and then allow the user to save them in the documents folder. If you need them to start in the documents folder, have the application copy them in, and track somewhere that it has done so.
If you do try to automatically install these through Windows Installer, the simplest approach is to make per-user components with key files reflecting the documents location, and ensure your application's shortcuts are advertised. Launching through an advertised shortcut will scan for missing key files, and then auto-repair will install them. But auto-repair is not an experience that users like, and this approach will replace the files if the user deletes them all. (Alternately you can use a per-user registry key as the indicator, which may be less likely to be deleted.)
I know IIS allows the creation of Publish Profiles that can be "imported" into Visual Studio in order to upload a site directly into IIS (since I'm already using it).
But now I have a more specific question regarding the use of these publish profiles in Visual Studio.
I have a solution for a web application that comprises a couple different components that I'd like to keep sepparated in IIS.
Namely, I have the web version, a mobile version and a couple webservices in this project.
What I'm configuring the server to do is have the webservices, mobile and website separated into different sites and use different publish profiles to publish them, each into it's own place.
Since I have all of these components into a single visual studio project, would it be possible to have publish profiles that publish a single component of the project without requiring me to do a "full publish"?
Or is the only solution to have separate projects? (even if they are all in one single VS Solution)
Visual Studio's web publishing feature assumes that projects map to atomic components1. There isn't a way by default to specify how to only publish a subset of the project. Partly this stems from the build system (MSBuild) that the Web Publish Pipeline (WPP) is built over.
Options you can investigate:
Make your site contents match the structure in your project. Deployments are incremental (if coming from your machine), and you can deploy specific files or folders from the VS Solution Explorer. If you need to republish your binaries, you're still stuck doing a full publish. Publishing individual files/directories is the exception to note 1 above, and only works for content file changes.
If you're up to the challenge, you could dig your way through the WPP targets (it's all MSBuild), and try to find a way to restrict which files are published. Then you could set up separate publish profiles within your project that each only handle a subset of the files.
The easiest way, especially if you're automating this, is probably just to use separate projects for each component. :(
I have a solution with two projects. I just marked the solution and checked it in and now all files have that little image of blue padlock on the left side which obviously means that they are marked as read only.
I've been working only with Tortoise SVN till now and this is my very first check in to TFS, so why does this happen, or if it is too complicated for an answer here, at least how can I return the state of my files (the entire solution maybe) to normal.
Also I've been struggling to find a good reading/tutorial on how to use/execute the basic tasks for TFS from Visual Studio 2012 so if someone can share a good source of information about the topic it would be much appreciated.
This is, in fact, normal. You are using a "server workspace", or connecting to a TFS server from before TFS 2012. Team Foundation Server has multiple modes of working:
A Checkout/Edit/Checkin system (via "server workspaces") means that you will need to explicitly check a file out to begin editing it. Files are kept read-only in order to indicate to you quickly what files are checked out and which files need to be checked out. If you simply start typing in an IDE or editor that understands TFS version control (Visual Studio, Eclipse) then the IDE will check the file out for you. Otherwise, you will need to check the file out manually (by selecting "Check Out for Edit" in Source Control Explorer or by running tf checkout <filename>.)
This type of system is very useful with teams that have very large repositories or very large files in those repositories; by explicitly instructing the source control system that you are editing a file, you avoid the need to scan the filesystem.
An Edit/Merge/Commit system (via "local workspaces") means that you do not need to take any explicit action to check a file out, when you query your pending changes, the disk will be scanned to determine what changes you have made. Local workspaces are the default in TFS 2012, though you or your administrator may change this default.
This is similar to the way Subversion operates and is generally suitable for most repositories, however if you use keep large binaries in your tree, it is probably not a good option.
A Distributed Version Control system (via git) means that you have a complete clone of the repository locally and allows you to work completely independently while offline and share your changes or receive other peoples changes as you see fit. Git is new in TFS 2013 and Visual Studio 2013.
This type of system is very useful for highly distributed teams and teams that want to take advantage of novel branching strategies but may not be appropriate for teams who have very complex requirements around fine-grained permissions.
If your server is TFS 2012 or better and you want to convert your existing server workspace to a local workspace, you can open the "Edit Workspace" dialog and in the advanced settings, change the type of your workspace. This will make all your files writable and you will continue working in a Subversion-like mode.
this is quite normal, having locks to the files.
However, you can set the level of source control of different check in / check out strategies.
link: http://msdn.microsoft.com/en-us/library/ms181237(v=vs.90).aspx
For the global documentation :
Source control : http://msdn.microsoft.com/en-us/library/vstudio/ms181368.aspx
Tfs global : http://msdn.microsoft.com/en-us/library/vstudio/hh529827(v=vs.110).aspx
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.
I'm attempting to use Web Deploy to Publish a Web Application.
I want Visual Studio to delete any files that no longer exist, so I've checked the "Remove additional files at destination" setting in my Publishing profile.
However, I want VS to ignore the /Content/uploads folder, as it contains contents that my users have uploaded. Naturally, the contents are different in my development site than they are in the live site.
Unfortunately, I have been unable to discover a way to make Visual Studio ignore this folder when publishing (it wants to delete all of the content, since it doesn't exist in the project).
Does anyone know of a way to exclude specific folders on the target site from being examined by Web Deploy?
I had a similar problem, wanting to keep some files in the deployment package even though they're not part of the project.
Try to create a custom MSBuild target for this, that works for me.
Here is a Getting Started MSBuild reference
Hope this helps.
All the best.
I was unable to find a suitable solution for this issue, so I've created my own:
https://pubsync.codeplex.com/
PubSync enables quick and reliable file syncing for publishing Visual Studio projects.