Environment: VS 2010, Windows 7, TFS
I have a solution1 with solution filder called Binaries(which is a physical path on local
computer, say it's c:\Binaries): I put all external assesmblies in this folder.
In another solution2, for each class library project in this solution, set property->build->Output path to c:\Binaries, so that the latest version of these assemblies can be referenced by any project in solution1
It's working fine.
Now I put solution1 and solution2 to TFS and all of them are under TFS source control, include Binaries folder.
Now I open solution 2 again and build the solution2, it give me permission error for each class library project like:
Error 49 Unable to copy file "obj\Debug\mycomponent.dll" to "....\Binaries\mycomponent.dll". Access to the path '....\Binaries\mycomponent.dll' is denied.
But if I check the permission in windows 7 on c:\Binaries, no problem.
So it should be something wrong with VS 2010 or TFS.
How to fix this problem?
Though I'm not a big advocate of binaries in your source control, there's a workaround for this.
When you get your source, you will need to specifically check out the binaries (to enable write access).
HOWEVER! If you have multiple developers working, this will (by default) put an exclusive lock on the binary files. And they will not be able to check out the files for edit.
The solution for this is in Visual Studio 2010. Go to
Team->Team Project Collection Settings->Source Control File Types and find "Executable Files" on the list. Change File Merging to Enabled and you'll be able to have shared locks on the file.
The other option is to either not "get" your binaries folder, or, if you do get it, "unget" it using
tf get "$/blah/project/Binaries" /server:servername /version:C1 /overwrite /force
You'll need to supply the itempsec and servername. This will get the first version of the binaries, which doesn't exist, so it will wind up deleting them locally and marking them as not gotten (or checked out).
Related
Currently through Azure Devops, I'm setting up a .Net Desktop type with pipe-line that includes assembly libraries. In my understanding this should've work if the scenario was TFS is on-premise and I can just install any 3rd party non-nuget libraries in that server and make the build work. Right now I was able to make this work by literally copying the .dlls but I felt its more of a hack than actually letting the build know that I'm referencing assembly / non-nuget package libraries.
I'm pretty sure i've missed something, is there a way to properly set this up?
Even though it's not a recommend way, but you could check in these libraries/dlls in source control. TFS could download them from server to your build agent and refer them.
First, make sure your local build is successful and if just the TFS build is failing then it is usually due to dll reference path issue. Make sure that the Dll is referenced as a relative path in the project file (.csproj).
To add a relative reference in a separate directory, such as C:\tfs_get\Sources\assembly\abc.dll, do the following:
Add the reference in Visual Studio by right clicking the project in Solution Explorer and selecting Add Reference.
Find the *.csproj where this reference exist and open it in a text editor. Lets say your .csproj location is c:\tfs_get\sources\myfolder\myproject\myproj.csproj
Edit the < HintPath > to be equal to
..\\..\assembly\abc.dll
This build will work properly with the assumption that the folders ( assembly, myfolder) under the sources folder exist in TFS.
Update
Have a folder named "libs", or "libraries", for example, that contains all the assemblies required by your projects to compile and run.
Reference these assembly by right click the reference folder of project and browser to these assemblies files.
For build, in Source Settings (XAML, Build Agent Folder)/Repository, keep the similar structure.
More details please take a look at this similar question : How to properly check in DLLs/assemblies to TFS/Visual Studio Team Services (was VSO)
How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".
What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.
So for example the .sln file is in:
D:\tfs\repository\main\SolutionA\solution.sln
and the dlls are in:
d:\tfs\repository\main\SolutionX\Dependencies\Binaries
What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:
1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution
4- successfully build
What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.
Some suggestions that don't involve creating pre/post build scripts are appreciated.
When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.
One work around is to...
SOLUTION SETUP
Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
Open your solution in Visual Studio (i.e. MyApplication.sln)
In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
Check-in your solution to TFS
SAMPLE FILE STRUCTURE
Main
MyApplication.sln
Source
MyProjectA
MyProjectA.csproj
MyProjectB
MyProjectB.csproj
Dependencies
Assembly1.dll
Assembly2.dll
You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:
"The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution."
Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.
Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.
Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.
I am using VS 2010, trying to debug (F5) a solution that is saved in a shared Dropbox folder, but I get the following error:
Could not load file or assembly 'Microsoft.WindowsAzure.Diagnostics' or one of its dependencies. Access is denied.
If it's worth noting - my partner is the one who created the solution.
This is an annoying bug in VS when working in a shared folder (when you didn't create the solution yourself). Try to clean the project. This might do the trick.
Do you have installed Azure Visual Studio Tools?
http://www.windowsazure.com/en-us/develop/downloads/
The dll for the azure sdk is probably not located in the dropbox folder. It is usually installed on the local drive.
You can either install your own, as long as the path is exactly the same (not recommended in case you guys decided to upgrade, then you would both need to remember to), or copy the dll into the dropbox folder and re-add it in the solution, so that you both are pointing at the same one.
I am using Visual Studio 2010 to develop an MVC 3 application for Azure. We are using AnkhSVN for subversion control, which has been slightly buggy in the past.
The error I'm getting when I try and Build/Debug my application is:
Unable to copy file "C:\Xxx_bin_deployableAssemblies.svn\all-wcprops" to "bin\.svn\all-wcprops". Access to the path 'bin\.svn\all-wcprops' is denied.
The story gets more convoluted, since this error is not thrown on another one of our developer machines, just on mine. The only real difference in our machines is that I have SP1 installed on mine.
Also when I updated AnkhSVN and re-checked out the app from the subversion server it work without throwing an error for the first build. After shutting my comp and then starting back up there error popped back up again.
Update:
I still haven't found a real solution. I just delete the .svn file in the folder and that takes care of the issue with Building the app. However, when I update or commit it throws an unversioned error.
I think the problem is that the app is trying to copy the .svn file over during the build, instead of just ignoring.
Do you know of any way to have the .svn file to be explicitly excluded from the build?
I need to resolve this issue asap, so any help is great!
Thanks
I received the same errors after I versioned my MVC 3 app for Azure on VS 2010 SP1. I was able to resolve this issue in three simple steps.
1.) From the VS 2010 Solution Explorer, click 'Show All Files'. This will show the hidden 'bin' and 'obj' folders in your Web/Worker role project. Right-click and delete both 'bin' and 'obj' folders.
2.) In Windows Explorer, browse to the folder that is versioned (should be your root solution folder). Right-click -> 'SVN Update'. This will download and put back the 'bin' and 'obj' folders that you deleted in VS. This is necessary because your project will exclude these folders from the solution, however SVN will still think they are part of it.
3.) The final step is to delete these files from your repository. In Windows Explorer, browse to the project that contains the 'bin' and 'obj' folder. Select the 'bin' and 'obj' folder -> right-click -> TortoiseSVN -> Delete. Go back to the root versioned folder and SVN commit to remove them from the repository.
The next time you build your Solution, the 'bin' and 'obj' folders will be recreated. Just make sure you don't add or commit them to your repository.
I fixed this problem by going into Windows Explorer and changing the properties of the folder to not index (look in advanced settings) and then manually copying the files giving me errors.
I had the same problem and fixed it.
You have your build output checked into SVN. This Azure target (that's complaining) should only be messing with \bin, \obj directories during a build. It will be cleaning and building. This clashes with .svn as source controlled files under .svn have hidden files and folders with read-only access. Therefore the build runs and subsequently breaks when the Azure targets try to delete/move the .svn files.
To fix just remove your build output from SVN (anything in \bin or \obj). You should not be placing these files into source control anyway as the rest of the files in SVN produce this output, so there is no reason to save it separately. Then you can delete the bin/obj etc folders and you should no longer experience the issue.
If you just delete the bin and obj files as other people have suggested then you're just leaving the problem for the next poor sucker that checks out a clean.
I had the same problem. It appear that the project bin folder was "accidentally" also committed into the svn. After removing the bin which of course shouldn't be in the svn the problem was solved.
Now it is still needed to understand why the build try to copy the sv folder to the bin.
Somehow another application keeps the file locked while Subversion (below AnkhSVN) tries to replace it with a different version.
Usually this is caused by a virus or index scanner. Retrying a bit later usually resolves this issue.
Sometimes a Subversion "Cleanup" (Solution explorer->(relevant node, E.g. Solution)->Subversion->Cleanup) is required to recover from similar errors.
I also had this problem. The cause for me was that I had created the bin directory myself instead of letting VS create the bin directory. Once I deleted the bin directory cleaned the build and did a rebuild, everything worked fine.
(I know I am using Visual Source Safe, I do not have a choice because it comes with the MSDN Subscription license and my company does not want to buy a third party source control solution....)
I have a VS 2005 solution with 3 C# class library projects, 2 ASP.NET web site projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference a common library DLLs that handle common taskes.
When a new person sets ups the solution on their workstation and build it for the first time, it checks out the common library DLLs in the bin folder of the ASP.NET web site and web service projects. When another developer that is currently working on the project tries to build, they receive a "file excludely checked out by other user" message.
VS 2005 does not display the check mark next to the DLL that is causing the headache.
Is there a way to prevent this from happenning?
Why do you have the bin folder checked into SourceSafe? On projects I've worked on, the third party dlls were checked into a separate folder (maybe called ExternalLibraries or ThirdParty) at the same level as the solution file. The compile process would be set up to copy the dlls into the bin folder. This could be handled with .refresh files, or with a pre- or post-build step. This way, VisualStudio/SourceSafe won't see the files as having been updated, and won't try to check them out.
If the compile is already pulling the files in due to them being dependencies, I'd suggest removing the bin folder from VSS. This is not the same as an "Exclude folder from project" which hides the folder from VS05 when compiling (and gives you the compile error you mentioned.)
If the third party dlls aren't going to change, another option is to make those files read-only in VSS. This way, no users will be able to check out the files. (To mark the files read-only, you will need to change the permissions from the VSS management tool; the developer's tool doesn't have that feature.)
As for why it happens, I don't believe VSS checks the binary version numbers - it is only concerned with modify file date. If a new developer pulls all the code out, all files (including binaries) will have the current date as the modify date. This may be causing the unnecessary checkouts.
Regarding your later comments - I'm not sure why VS05 wouldn't see the files as under source control but the VSS UI does. I suspect it has to do with the .vss files (and similar) that are in that folder. In this case, VS05 is incorrect.
Not sure if this is the problem or the best fix, but if you update every developer's machine so that they have the same latest versions of the common DLLs installed, this shouldn't keep happening. I think VSS checks out the DLLs in the \bin folder if the version referenced by the project file doesn't match the version installed on the developer's machine.
#Pedro:
In the VS 2005 IDE inteface, it does not indicated that the \bin folder is in VSS. When I look at the project in the VSS UI, it shows that is checked out to the user who did the latest build on their workstation.
If I use the "Exclude folder from project" option, it will cause the compiler to throw "reference not found" errors.
In my solution structure, the class library project creates a reference to the third party DLLs using the "Add Reference" command. Then I set a project reference to the class librarys in my ASP,NET web site and web service projects (using the web site project template). Because the class library has a dependency on the third party DLLs, they are copyed in the \bin folder.
How do I set a file to read-only through the VSS UI?