I'm using visual studio 2012 and SVN (tortoise) repository. I want to block some developers access to some source files, but I need the solution project compile ok. So I can't quit any file from it, and I don't want to use compiled dll. I want to know if exist some software /plug in / app that to controls some access permission to view/get files into VS. Any Idea ?
You could obfuscate the source code. (e.g. give variables cryptic names)
If this is an option, take a look at this thread.
Related
We have a Libraries folder where we keep third-party DLLs and our own utility DLLs for all applications to reference. I want to do development against one of our utility DLLs and an application that consumes it at the same time. But if I check out the library DLL to change it for temporary local use, TFS insists on checking it out exclusively, which trips other people up. I understand the reasoning behind it doing that (hard/impossible to merge a DLL, so two people shouldn't be working on one at the same time), but I just want to mess with my local copy while I'm working on the library it represents.
I suppose I could delete my application's reference to the DLL and recreate the reference pointing to some other place, but of course this just begs for me to forget and check it in like that, which would obviously be bad. Not to mention that this is a pain in the neck.
How should I proceed in such a situation?
You are using a server workspace that does not allow editing outwith TFS. In TFS 2012 local workspaces were introduced which do not have a read only flag for files and you are free to edit at will.
You can change your existing workspace in a few clicks: http://msdn.microsoft.com/en-us/library/bb892960.aspx
You could just go into the file system and mark the file as writeable. Once you are happy the binary is good you could check it out, copy the new version of the file over and check it back in again. TFS marks binary files like this as locked for good reason, as you can't merge them in the way you can with textual content.
The best approach would be to use a NuGet repository to manage your binary dependencies, instead of relying on binaries checked into source control.
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
It's very straightforward to add languages to an installshield project. My goal is to
make a modified English (0x0409.ini) with some of the strings modified, such as
However I have a team of people that would have to copy these files to a directory much like C:\Program Files (x86)\InstallShield\2012Spring\Support andC:\Program Files (x86)\InstallShield\2012Spring\redist\. This is even worse with the 10+ machines in the build farm that could potentially need this file. It's a non-starter. It's hacky to have modify the install of a tool to get it to use an unsupported language.
Is it possible to check the language file to SCM and have it reside in a subfolder of <ISProjectDir>?
I don't believe so. I think you'd have to set up a post-build step that would copy in a modified ini file.
You could set up one in installshield's UI but I don't know if that persists in a stand alone build.
My team has been developing a software package for a while. The code is under source version control. Until now, every developer has been setting up their own development environment manually (we use Visual C++, recently upgraded to 2012). Now that the structure of the project has grown more complicated and the build configuration is non-trivial, I decided to create a portable solution and add it to the source control system for the convenience of newcomers.
The problem is I need the developers to be able to set up the solution according to their particular needs (mostly preprocessor #define's) without disturbing the solution for everybody else.
VC++ is creating a .user file for every project that seems to be designed to hold settings on a per-user basis, but I'm not sure how to add settings so they are stored in this file (which I exclude from source control) and not in the project file or the property sheet files (which are included in source control).
How can I accomplish this? Thanks.
I've written some unmanaged C++ COM DLLs that rely on native C++ DLLs not in the system path. When I build the associated projects without copying the DLLs into the Debug/Release directories I get the infamous PRJ0050 compiler error.
Clearly I could copy required DLLs all around the solution, but I'd like to avoid this. I know I could set project properties Linker->"Register Output" to No and then run regsvr32 directly during a post build step.
My question is if there's a better way to do this. Is there a way to use the automatic "Register Output" option with a custom path controlled at the project level? What am I missing here?
Edit: Originally I'd been thinking "Register Output" did some magic like un-registering on a clean, but that isn't the case. The only thing special it seems to do is pick out the proper way to register different types of projects.
I am not sure what you are asking - but there are post build steps you can do. For example - if these are 3rd party libraries/DLLs you can have them located in a known relative path or in a directory named by an environment variable.
This is not an unusual scenario from what I can tell of your situation.
Can you add a DLL as part of the project (wherever it is located) and as the build step for that do the registration. Or you can make the build step for that a file copy and registration
Again - I am not exactly sure what you are asking and why your 2nd paragraph is not acceptable to you if it works