I have a Web Setup project in VS. I'll be switching to WiX, but that's in the future and currently I need to solve the following issue.
I need to exclude some common dlls from the project. So I build the project, VS updates the list of Detected Dependencies. I exclude them and the setup builds. I check the file list with Orca and the files are not included in the installer.
But when I clean my output directory, reload the solution and do the build, some of the dependencies do not show as excluded! And so they end up in the MSI. (This is what is happening on the build machine).
I think that the problem might be with the fact that these are second-level dependencies:
my app -> NHibernate.dll -> Antlr3.Runtime.dll
(Antlr dll ends up in the MSI).
Is this a bug or am I missing something?
I found this page on msdn that has a work-around for the Exclude flag being reset to False:
Previously excluded files are included again when the solution is re-opened
When you exclude a file from a Setup project, you may see that the file is included again after you close and re-open the solution. This may occur if there are two copies of the same DLL file from two different source locations.
To work around this error, change the Copy Local property on one of the files:
In Solution Explorer, click on the DLL reference that you want to remove.
On the View menu, click Properties Window.
Change the Copy Local property to False.
Related
i am struggeling for a while now with removing unused dependencies from bin output folders.
I am for example writing a small .NET Wpf program which gets its data from a Web server. Therefore i installed the System.Net.Http NugetPackage to make my Get / Post requests. The Package Information is stored in the .csproj file.
When i compile the project a lot of Dependencies are added to the output folder
Sytem.Security.Cryptography.Algorithms.dll
Sytem.Security.Cryptography.Encoding.dll
Sytem.Security.Cryptography.Primitives.dll
Sytem.Security.Cryptography.X509Certificates.dll
...
None of these dependencies are explicitly used in my program, means when i delete them from the output folder and start the application everything works as expected.
I do understand that this Dlls has to be in the package, but how can i ignore them. Is there a way to ignore dependencies within a nuget package?
One way to accomplish this is to set copy local to false on the Dll reference.
I haven't worked on WPF projects but I believe this would still apply.
To do this expand the References node in the project, select the Dll and then in the Properties window set the "Copy Local" property to False.
This should prevent the Dll from going into the bin and also from being included when published.
One word of warning though, the application may work now but doing this creates a potential trap for future you or other developers. If code changes down the road require one of these Dlls your application won't be so happy and then you'd have to remember to put the Copy Local back to True.
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.
I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
(I no longer want an answer. OML, my English has surely improved...)
How to use assemblies in a VS solution under source control and keep assemblies updated?
(Source control is provided by the codeplex and VS default options for it.)
I mean,I have a project named HyperAero.
I have another project named TestAnimation.
TestAnimation is under source control and needs hyperaero.
When I check in,HyperAero.DLL will not be saved in server.Of course,I can add hyperaero.dll to my solution as a file but I want it to stay updated with my changes in HyperAero project automatically.
What should i do?
Answer (Got it myself):
command:
robocopy "E:\Documents\My VS\Fix soft HyperAero Form\Fix soft HyperAero\bin\Release" "E:\Documents\My VS\Fix soft Animation Maker\Test of Animation Maker\DLLs" "*.DLL"
set rce=%errorlevel%
if not %rce%==1 exit %rce% else exit 0
Similar Question (Remember that i want my assemblies to stay updated):
When using custom assemblies in a visual studio project. How does one check in those assemblies in source control with the project so that anyone can download the project and build right away.
There are two way to approach this:
1/ Don't put the assembly dependencies in source control and always include in your solution their Visual Studio project instead. In your case you'd have a solution with the Hyperaero project and TestAnimation project with a project dependency to the Hyperaero project.
This way you don't have to put the generated DLL in source control and keep it updated each time you change something in the code.
2/ If you really want to dissociate both projects, then I'll recommend you to use Nuget and build a Nuget package for the Hyperaero project and then reference the Nuget Package in you TestAnimation project. This approach is the cleanest one, but it may be overkill and at last it's not something you'll setup quickly (compared to 1/).
Put both projects in the same solution and add a project reference.
Use your source control's UI / command-line to add the DLL files.
What source control software do you use?
If you are using subversion:
ankhsvn (Visual Studio plugin) can handle multipe repositories in one solution.
I have the following structure.
- App1\
App1.sln
App1Forms\
App1Forms.csprj
- App2\
App2Dll\
App2Dll.csprj
Now If I open App1.sln and add App2Dll, which is outside the folder structure, as a project, the project gets linked as a relative path. I am fine, if I check out both sources to the same parent directory.
Ankh is aware of that and If I hit update both projects gets updated.
If I want to commit changes I am only allowed to commit to one repository at a time, but again, ankh informs me about that.
Another way is to use svn-externals http://svnbook.red-bean.com/en/1.0/ch07s03.html
which will transparently include one repository inside another.
How specifically should my command line be written as to copy the output from one project into the output of another project? The list of macros that are avaliable does not list anyway of accessing OTHER project directories under the same solution:
http://msdn.microsoft.com/en-us/library/42x5kfw4(v=vs.80).aspx
Here is what I currently have:
copy "$(TargetDir)FILE_TO_MOVE.EXE" ""
What should I put in the second quote to complete this command?
NOTE: A similar question does NOT actually show you HOW to do it, which is what I am asking: Visual Studio 2008: How do I include project output as an embedded resource in another project?
It is much easier to do it the other way around, have the project that has the dependency on the file also copy the file. Which you can do in the IDE without pre/post buid event or macro trickery.
Ensure the source project is built. Right click the target project, Add Existing Item and select the file. Click the added file in the Solution Explorer window and set the properties to Build Action = Content, Copy to Output Directory = Copy if newer. And right-click the target project, Project Dependencies, tick the source project to ensure that it always gets built first.
I am assuming that yout are copying the "FILE_TO_MOVE.EXE" in the post build events of your project.
The thing about the build events in Visual Studio is that they are run just like a batch file, therefore I beileve that the easiest way to solve your problem is to use a system environment variable in your project... This way your code would be similar to the one below.
copy "$(TargetDir)FILE_TO_MOVE.EXE" "$(MyVariable)"
Note: Visual Studio doesn't let you use your environment variable like this: %MyVariable%.
I think the correct way now would be to simply add your secondary project, i.e a Windows Service, to the References of the main project.
For example if you have a main GUI project (that the solution was created with), and a second Service project added to the solution, adding it to References of the GUI project will cause the EXE and the PDB of the service to be placed in the Debug/Release folder of you main project.
I am not sure if you still need to add the Project Dependancy as Hans suggested . This is probably automatic thanks to the reference.