I have the following problem: I need to create a VS project (database project) and I want to make it deployable. To do that I need to add a single SQL function, which belongs to a pool of global functions, to the project. If I now deploy the project, I have all the files that I need.
Problem: I don't want anyone to change the global function inside of my project, so I would like to set it to readonly (not the file itself on the filesystem, it's checked in tfs anyway), so that the file can be deployed, but no one can change it inside the project (at least not by accident).
Is it possible to add a file as read-only to a VS2010 project?
Related
I have to share some code between multiple projects in Unity. This code is under constant changes during work on projects. So I need my code to be shared as separate assembly and be included in each Unity solution in Visual Studio 2015.
What is the way to make changes in common assembly so that it automatically updates for other projects and for Unity editor?
Your solution is in submodules with version control. You have one repo for the main project. Then you have a folder within that is another repo. This one is a submodule. It appears grey on your main repo and does not go into commit.
https://git-scm.com/book/en/v2/Git-Tools-Submodules
It does work with other version control systems.
The point of that pattern is that you work on project A with utility-submodule. utility is a folder inside Assets folder. Then you modify Utility.cs and push it on Utility repo.
Project B is using utility-submodule and make a pull, your modification are there without altering the rest of Project B. Obviously, this includes all the hassle offered by version control, that is, conflicts if Project B has worked on utility, probable breaks on other projects if you change the implementation of utility and so on (nothin unusual though).
On the other hand, it is an easy way to pass common code over independent projects.
Let's say I have my shared project here: c:\UnityProjects\DesignPatterns\
and need to include in my Unity project here: c:\UnityProjects\Game\
Solution:
Move all shared code into separate project (c:\UnityProjects\DesignPatterns)
Include this project in solution for all your Unity projects. This allows you to make changes once you need them without reopening shared project separately.
Everything works fine at this moment except Unity editor can't see your external assembly. You have to copy it into any assets folder in Unity. Unity will automatically detect it and create .meta file. Let's create folder for this: c:\UnityProjects\Game\Assets\ExternalDLLs\
We don't want to copy recently built assembly into this directory, we want make it automatically. And Visual Studio post-build event command line is here to help with that. Right click on CSharp project and select properties, then go to Build Events tab and add the following line into post-build event command line:
xcopy $(ProjectDir)..\DesignPatterns\bin\$(ConfigurationName)\DesignPatterns.dll" "$(ProjectDir)\Assets\ExternalDLLs\DesignPatterns.dll" /Y
Now each time we make solution build this command copies our dll from output folder of shared project into our project's asset folder.
Please note: shared project must be built before your unity code assembly is built. It is the case when you always make solution build. In other cases consider copiing assembly from Unity temp directory (you have macros for this folder to select).
So that every time I create a project using the libraries I usually use I won't have to manually add the sheet.
You can do this, but I advise against it. Main reason being it will make your project files unusable on other machines unless you also force your solution on them. Second reason you cannot expect all your projects ever are going to use the same libraries/versions/configurations of those libraries so after a while it might become unmaintainable.
You are imo better of creating a small utility which copies a project from a template you create with all imports and then changes guid and project name. Or create a template for VS which does that.
Anyway: a possible solution is to add an msbuild file which imports all default property sheets you need into the $(VCTargetsPath)\Platforms\Win32\ImportBefore\ directory (create it if it doesn't exist). The file has to have a .targets extension. More info here for example.
I'm part of a large developmentteam with a big project that is built with TFS 2013. We have gotten the build to work with automatic tests and web transformations as well as deployment to correct folders. The last part we need is a way to copy additional files to the drop location with regards to different environment.
We have a folder in the solution that contains several deployment files for different environments. We build for several environment with each build.
The folder looks like the following:
A folder named contains several powershell scriptfiles
(Deploy.ps1, RunDeploy.ps1, StartService.ps1)
The first file should be copied to the root of the drop folder location for each configuration/environment.
The last two files should be copied to a new folder named Deploy under each configuration in the drop folder.
Additional to this we have several settings files in the same sourcefolder. One file for each environment named settings-.txt
These files should be copied to the Deploy folder for the correct configuration under the drop location.
We are using TFS 2013 so preferable using a custom workflow but we can use a target-file if needed.
Any idea how this can be created?
Where should I start?
I have been unable to locate a variable in a custom task in the build process that contains the location of the dropfolder for each configuration.
I managed to create a custom task in the build template after some searching for the variables I finally could create a custom task that created the correct folders and located the files that needed to be brought along in the build.
To find the variables I used the common task GetEnvironmentVariable with the specified variables. To see what each variable contained I added a print line just afterwards and tried the build and then when I had found the needed sources of information the task to create a custom build task was fairly easy.
I am wondering if there is a way to set the deployment setting under Local.TestSettings in a Visual Studio 2010 Test to a relative path. Right now we have to copy over a couple of DLL's in order to use our tests correctly. We have this path hard set on a machine, but this gets messed up if you accidentally commit that file and then someone updates.
You can use test setting to add one deployment item. And continually use notepad to edit the *.testsettings file. Then, manually add "outputDirectory" attribute to the deployment item.
For example, there is one folder named "Config" in "myProj" which contains your online codes. And you want to copy all configuration files under the folder - "Config" to your test project - "Test.myProj" and make them also be placed under "Config" under "Test.myProj"
So you need to manually change the *.testsettings and add the following item in the file.
<Deployment>
<DeploymentItem filename="myProj\Config\"
outputDirectory="Test.myProj\Config\" />
</Deployment>
P.S. VS2010 did not allow to input value to "outputDirectory". So u have to use notepad or text editor to update it.
What is the source for these DLL's? How are they being used, as reference DLL's? If they are third party DLL's the tactic we usually do is place them into a "Reference DLL's" folder and add them as deployment items. When VS goes to execute the test it will copy them to the OUT folder along with the test DLL. Now that they're both in the same folder your tests should have no problem finding the needed reference DLL's.
If these DLL's are of your own creation (or your group/organization) I would add the project to the solution then add the reference as a Project reference. VS will automatically detect the dependency and compile the additional projects and copy the built reference DLL's to the out folder.
We have different dev environments between developers here. When I build, I want my compiled files to be copied to a bin folder located in C:\Web\bin\. Another developer may want those files dropped in C:\Web_2011\bin\.
Using Visual Studio 2010, the way we work this now is to run a BAT file with the directories defined as parameters that need to be changed if pulling from another developer's branch.
Is it possible to store a solution-wide parameter, (in a .user or .suo file maybe,) to define where a developer wants to drop his builds?
You could do it through the project file (.vcxproj for C++ project for example).
The simplest solution would be to add a Custom Build Step that runs some batch file. This batch file could check the current user name and copy the files based on that.
(An even simpler solution would be to run a user specific batch file from his local disk)
If you really want the fully fledged solution that will allow you to save this data to the user file, you can do it by editing the project file and adding a PropertyPageSchema element that extends VS property pages with another parameter (your destination directory). You can define the Persistence attribute of DataSource element as "UserFile" and the data will be saved on your .user file. You will need to add some target that actually uses this data (copies files to the directory specified).
For more information, read about msbuild and PropertyPageSchema.