I am trying to make setup project for my application.
I have added it to my solution with my primary application project. Everything looks fine. I can see detected dependency files:
But i must change targetName of some files.
I can't do that and I don't know the reason why?
You can see the "TargetName" is gray and unchangeable. I should be able to rename all files I want if I'm installing them on other machine.
How can I change TargetNames in my Setup Project?
Don't think it's going to let you do that without renaming the .dll. The deployment doesn't seem to allow one to change .dll names ... which makes sense, really: you've compiled with the expectation that you're going to have Jacob.Vst.Interop.dll as a reference, so if you remove it, and you're not installing it into the GAC, you're going to have some trouble.
Related
So I have a problem facing VS code changes.
Whatever changes I have applied to my solution and built, it is working fine and I can see those changes being applied when I debug. But the same changes aren't applying to the .exe file.
I have tried release build as well, Same with that. It Debugs the release build fine but doesn't apply those changes to the .exe file.
It Debugs the release build fine but doesn't apply those changes to
.exe file.
When you debug the project, VS debug engine will try to fetch the output project.exe and project.pdb for debugging. So if the debugging works well(those changes being applied), the output project.exe should also work without any issues(changes applied).
See this(for C++, similar situation with C#, VB):
This error message comes when VS debug engine can't find the output .exe, that's why I say if the changes are applied during debugging, it actually indicates the changes have been applied to your .exe file.
Let me name the project which outputs the .exe ProjectA, other projects in your solution are B,C,D. Here are two directions you can check:
If the code changes you mean is in Project A:
Right click project A in Solution Explorer=>Properties, check the value of your Output Directory(C++) or Output path in build tab(C#), it represents where the output .exe will actually exist, and VS debug engine will fetch the .exe in this path.
So make sure you tested the .exe in this path instead of old versions from other locations.
If the code changes you mean is in B,C,D, and A depends on B,C,D:
In most of the time VS will help copy the assemblies from B,C,D into A's bin folder, but I'm not sure if something's wrong with your environment which breaks this. You should make sure all the assemblies in your bin folder are updated.
I think this issue comes from your project instead of IDE(create a new simple project to check if the issue occurs in it). And in which way did you check if the changes are applied? Make sure you use the same way no matter checking during debugging or checking the .exe.
Updated:
According to Sandesh, this issue could be resolved by a clean(clean
old versions completely) rebuild.
Right click your project and click property, in General page, set "Enable Managed Incremental Build" as "Yes". It will replace the old exe file after every builds.
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.
The way I am going to do is create a SolutionItems directory inside my solution and physically copy all referenced third-party dll files into that folder, then I change reference to that local copy inside the SolutionItems directory. But the question is: does it worth the trouble of manage it manually?
I would think it is a good idea as it is dependency for my application. Without including the dll file, the whole solution wouldn't be able to run inside Visual Studio if the machine don't have the required DevExpress version installed. My Deployment Project will handle dependency correctly regardless, as far as the reference been setup properly.
On the other hand, because DevExpress will normally automatically add references, and I can using Project converter to update version of DevExpress. So without reference to the Local Copy inside solution, it is pretty much working out of the box whenever I am changing reference, or change between DevExpress versions. If instead, I am managing my local copy, I am create more work for myself to maintain the reference and physical copy of dll files. Should I keep it simple as it is now, base on the assumptions that whoever working with this application will need have a copy of DevExpress installed?
We had a similar problem where I work. 5 devs, 1 svn and mulitple copies of DevExpress dlls floating around. We tried at first maintaining a local copy (updated manually) as you describe, this did not work well for us. So yes, the easiest thing to do (in my experience) is require everyone who works on the project have a copy of DevExpress installed.
In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?
I am writing a small application at the moment and am trying to organise my build output to be a little closer to the finished product. The application is made up of a number of different projects. There is a core library that contains most of the functionality, a GUI app and a command line app that both reference the Core Dll, and a number of Plugin Dlls that are loaded at runtime and implement different data sources, these all reference core.dll, these also may include some other third party dlls. There are also a number of peripheral files such as a readme. And finally the core.dll and the datasource plugins are unit tested.
I would like to configure my build so that everything is output into directories as I would expect it to be when installed. I want debug and release builds to be built into different directories but otherwise have the same directory structure. I only want tests to be built for debug builds, and want them to be runnable, but seperated (I guess all test dlls would get output into a seperate directory). Here is how I imagine the structure will be.
Code/
solutions etc here
Debug/
Project.Core.dll
Project.Gui.exe
Project.Cli.exe
readme.txt
lib/
ThirdParty1.dll
ThirdParty2.dll
DataSource/
DataSource1.dll
DataSource2.dll
Tests/
Project.Core.Tests.dll
DataSource1.Tests.dll
Release/
same as Debug but without tests.
Is there any way of getting a solution to build like this? I'm beginning to think it will be difficult to build the plugins and the app all from one solution, and probably not even wise, but as they will all be distributed together it would be nice. I am open to using Nant or another build tool if that will make it simpler.
It is possible. Just modify OutputPath tag manually in each .csproj in both Debug and Release file to something like this
<OutputPath>..\$(Configuration)\any_subdirs</OutputPath>
You can disable tests building for Release using Configuration manager.
Modifying each project every time you create a new one is annoying.
Here's the solution:
Locate the real vs project, it'll be somewhere under ("%programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates*")
Copy it locally somewhere.
Extract it.
Edit the contents making changes that better suit your project layout style. Make sure you update the project name, the name is what you see when looking for the project in the new project dialogue box. It's xml tag is Name, you'll find it in the {something}.vstemplate file.
Compress the content again. (Note: the contents must NOT be in a sub folder, so /* and NOT /{somefolder}/*).
Place your custom project under ("%USERPROFILE%\Documents\Visual Studio 2010\Templates\ProjectTemplates*").
Add a new project is Visual Studio, selecting your custom one, and enjoy!