I use Visual Studio 2013 with SSDT to develop my database projects. Some projects within solution have dependencies on others.
I create deploy/update script with Schema compare tool. I find differences between current project state and the latest project snapshot. After that I create new snapshot.
Now I have to use another computer. When I try to compare project and snapshot I receive a number of errors "The reference to external elements from the source named 'SOMEPROJECT.dacpac' could not be resolved, because no such source is loaded."
I think that the problem may be in folder names - previously solution was in "d:\projects\solution name\", now in "c:\solution name\". I can not use disk D: on the new computer.
Any ideas how to fix this?
Make a copy of someproject.dacpac. Rename it to Someproject.zip. Unzip the file. Open the extracted model.xml file. Locate the portion of the header that lists the references. Locate the referenced files. Place a copy of the referenced files in the same directory as someproject.dacpac. If that fails, then perhaps you could use the dos command subst to create a path that maps to the true location of the referenced files.
Related
I'm working on C++\CLI that someone else started. The solution is made up of 3 C projects and 1 C++\CLI project that uses them.
I've duplicated the C++\CLI project and change it name and ProjectGUID property in the vcxproj file.
The problem is I still get the error listed bellow.
How can I fix this?
Warning 1 warning MSB8028: The intermediate directory (Debug\) contains files shared from another project (my_project.vcxproj). This can lead to incorrect clean and rebuild behavior. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets 388 5 seebo_prod_line_tool
Same problem here, solved by
Deleting all Debug\ and Release\ folders (there were more of them in subfolders where I didn't expect them)
Changing the .sln file manually to fix the name of a referenced C++ project (.vcxproj) which apparently was not renamed when renaming the project in Visual Studio
My suggestion is to make sure the intermediate directory for each project is different (as suggested by someone else earlier.)
To do this,
Open the project's Properties dialog
Under Configuration Properties, select General
Make sure the Intermediate Directory for this project is unique to this project.
I ran into this problem because using previous versions of Developer Studio I had a host of companion projects but wanted all of them to put their output in a common "Release" folder. Inadvertently I had set the same common release folder settings in the Intermediate Directory path for some of the projects (but not all).
I found you can disable these types of warnings by added the following to the project file:
<PropertyGroup>
<IntDirSharingDetected>
None
</IntDirSharingDetected>
</PropertyGroup>
I myself also encountered this kind of warning.. But I obtained this in a different situation, I renamed my whole solution/project via IDE and thus making another copy of an entirely different project. So what I have here is a total of two projects sharing one common resource, source and header files. This makes this warning pop up.
I fixed this by deleting the files associated with the project, which you renamed previously. Delete these INSIDE the DEBUG folder. In your case, try deleting all 'my_project' files, regardless of any file extensions because it shares resource files to your duplicated project.
The cause of this problem is copying an intermediate directory that was created by Visual Studio, and that already contains files from a previous build. It is not a problem in the project settings, but a problem caused by the existence of unexpected files from another project. In this context the warning is benign, but annoying.
The minimal solution is to find and delete each such file. The simpler solution is usually to "super clean": delete every directory created by Visual Studio (with names like bin, obj, x64, x86, Debug, Release and so on), and allow VS to re-create them during the normal build process.
I have experienced this problem as well, and for me, the cause was that there were multiple libname.tlog directories inside the intermediate build folder. These directories contain libname.lastbuildstate files that I assume are used for dependency checking. Doing a Clean of the project I don't think will delete these extra directories.
So in this case I was able to delete the libname.tlog directories and build again. I don't know how it got into the state of having multiple directories inside each intermediate directory -- perhaps they were created when I updated the VS version.
We have a large solution containing many projects - I am trying to create a sub-set solution containing a single project but am running into a roadblock where VS is ignoring my path. I would like to retain the same solution path to prevent duplicate build steps which reference the solution folder.
D:\Dev\Sol1\Sol1.sln - contains N projects in subfolders.
- For example: D:\Dev\Sol1\Prj1\Prj1.csproj
When I create D:\Dev\Sol2\Sol2.sln, I can reference any of Sol1's projects, using ..\Sol1\Prj1\Prj1.csproj
If I move it to D:\Dev\Sol1\Sol2.sln, VS gives me the error:
The project file could not be loaded. Could not find file
'D:\Dev\Soln1\Prj1.csproj'
Notice that it is ignoring the subfolder structure entirely.
Any ideas or workarounds?
In my case I made a merge where projects were added on both branches. After all paths and counts were fixed inside sln, there still was a problem with "The project could not be loaded. Could not find file… " + very strange, never existing paths.
The resolution that worked: delete solution's suo file (personal settings cached project info and it caused the problem).
You need to edit the .sln file and update the paths to the projects.
We just started using TFS and it works great. I have one question though, if we delete a folder it's not deleted on my local workspace. We are currently reorganizing a project and I wish to not have heaps of unused folders on my local drive.
Where can I configure this?
Thanks in advance.
In you have the Visual Studio Power Tools (http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f) you can use the command line tools tfpt to clean up all your workspaces.
In a shell window
change directory to your workspace root
type \tfpt.exe treeclean /recurse .
This will remove any file or folder not in source control.
Another solution, which also checks how well your project is put together, is to cut the whole folder and move it elsewhere, then perform a get across the project. This will allow you to check if the project will build or if there are some "magic" DLLs missing. Anything that is missing can be retrieved from the copy of the structure and added into source control.
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.
I have two projects in one Visual Studio 2008 solution. I'd like to use the primary output from one of the projects as an embedded resource in the other, but for the life of me I can't find any way to accomplish this.
If I simply add the output file as a resource, then it doesn't seem to change when its source project is rebuilt. I even have the project dependencies/build order set up properly and this does not seem to help.
Anyone have any hints for me?
Thanks!
the best option is to "reference" the other project as if it were a class library.
that way you make sure the whole references tree is copied to your output dir.
When you add an existing file to a project, Visual Studio copies the file into the project's directory.
Any subsequent changes to the original file are ignored.
There are two workarounds:
Add a post-build action to the first project that copies its output file to the second project, and edit the dependencies so that the first project is always built first.
Add the output file to the second project as a link (Click the down arrow next to the Add button in the open dialog).
This will reference the file from its original location without making any copies.
Set the output directory of the project that generates the resource to point to the resource directory in the project that uses it.
If that's not possible for some reason, use a post-build command (also available in the project settings) to copy the file there.