So I have a web application in Visual Studio 2010. Im depending on 2 DLLs. One of these are not a "real" DLL but a COM object. The first DLL is wrapper for this COM object.
So the first DLL is easy to add with a reference and when I deploy it gets put in the bin folder on the destination. The problem is the COM DLL. I can not add it as a reference. So I tried the accepted answer on this How do you include additional files using VS2010 web deployment packages? but I could not make it work. (some comment suggest this edit should be in the .pubxml file but i don´t even have that one?)
I also tried the second answer on the same question but still no luck.
The only thing that works if I go to the project properties and select "all files in this project" but I really don´t like that.
I know these answers I refer to are a bit old so maybe there is a new way of doing this?
I have experienced a similar situation in the past. The only viable way around I have found was to manually copy the files I needed when building the application using the "Build Events" screen (Go to "My Project" > "Compile". It is a the bottom right hand corner).
In the "Post-build event command line", I have entered a script that copies the DLLs I need into the bin folder of my web app:
XCOPY "E:\ThirdParty\Example.dll" "$(TargetDir)" /Y /R
This script simply copies the dll "Example.dll" from a repository folder into the bin folder of the web app I am compiling. You can find a lot more about these build events on MSDN: https://msdn.microsoft.com/en-us/library/ms165412.aspx
Hope this solves your problem and good luck!
I managed to work it out. I found this http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx page and installed the update for web publishing.
After that I had the pubxml files and I edited it according to the guidelines.
As found on http://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/deploying-extra-files
Related
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.
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?
So I see two solutions to my current problem, but I was wondering what the pros and cons are, or if there is a defacto best practices approach.
So my current project has a number of configuration files, help files, and other external content. I need this content local to run and debug the application. Currently we duplicate this content in a standard windows installer project. This clearly is a bad idea. We are moving to a new setup that uses the WiX installer, and I'm currently setting the project up next to the code project and trying to figure the best way to share resources. I see two solutions.
One is that I can put all the resources in the WiX project and then add them as links in the code project. This way I know what I'm debugging is installer.
The other option would be to leave the content in the code project and path into it in the installer using the reference variables.
Right now it seems 6 one way, half dozen the other. Any persuasive arguments for either method?
Assuming that these configuration and help files are going to be installed in the same directory as the executables then definitely put them in the code project, mark them as Content, and add a reference to the code project to the installer project. If you're using WiX 3.5 the files will be automatically included in the installer along with the executables, which makes writing simple installers much easier.
For earlier versions of WiX or more complex deployment scenarios (where the content files could be going into different directories) you would still put them in the code project but then you'd use File elements with a relative path or reference variable in the Source attribute to include the the content files from the code project directory.
I don't believe that putting the content files in the WiX installer project directory instead of the code project directory will do anything to ensure that the version you use to debug will be the same as the version installed. That can only be ensured by thinking through the process of how your application finds these content files and making sure the right versions are found.
So going back to the simple case where the content is in the code project and marked as Content, and it will be installed and loaded from the same directory as the executables, then it is only a matter of setting "Copy to Output Directory" to "Copy always" or "Copy if newer" and then you can be sure the versions used in debugging and the version installed will match.
When I right-click my solution in the Solution Explorer and choose Properties I get a dialog where I can select the Startup Project.
I sometimes select Current selection (If it is an experimental solution with lots of projects I jump between), but most often it is a Single startup project selected, which would usually be the main WinForms applications or or Console application.
My problem is that whenever I do a treeclean with the tfpt command (Team Foundation Power Tools 2008) this setting is forgotten. So when I try to run my solution the next time, it has defaulted to some random project and I get an error stating that I cannot run a class library or something like that. Which is obvious of course. But where is this setting stored? Why is it forgotten when I do the treeclean? The solution file is still there, right? Isn't solution properties stored there?
Reference 1
Arian Kulp says:
I was struggling with trying to figure
out why a certain solution of mine
wasn’t starting right. It was in VB
with four projects. Upon initial open
it would set a certain project with a
DLL output as startup. If I set the
EXE as startup project, it was fine,
but when I distribute code I always
clean it by removing *.suo and *.user
files, and bin/obj folders. Upon
opening the “cleaned” version, it
would always revert to the DLL project
and fail to F5 nicely. The fix turned
out to be simple, though I’m curious
as to why I needed to do this at all.
In the solution file, there are a list
of pseudo-XML “Project” entries. It
turns out that whatever is the first
one ends up as the Startup Project,
unless it’s overridden in the suo
file. Argh. I just rearranged the
order in the file and it’s good.
I’m guessing that C# is the same way
but I didn’t test it. I hope that
this helps someone!
Reference 2
Setting the StartUp Project
Which project is the "startup" project only has any relevance for debugging, which means it's user metadata from the point of the solution and the projects. Regardless of which project is the "startup" project, the compiled code is the same.
Because of this, the information is stored as a user setting in the Solution User Options file (solution.suo) which accompanies the Solution file (solution.sln). The .suo file "Records all of the options that you might associate with your solution so that each time you open it, it includes customizations that you have made" according to MSDN.
The .suo file is a binary file. If you want to read or change it programatically, you have to use IVsPersistSolutionOpts.LoadUserOptions from the Microsoft.VisualStudio.Shell.Interop namespace.
I suspect that this setting is saved as part of the .suo file created whenever you edit a solution file. This file contains various user settings, such as breakpoints, watch data etc.
I cannot confirm this but that would be my guess.
Unfortunately its not XML its a binary file and not easily edited.
I just wrote a little command line utility for windows called slnStartupProject to solve this. It sets the Startup Project automatically like this:
slnStartupProject slnFilename projectName
I personally use it to set the project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on github:
https://github.com/michaKFromParis/slnStartupProject
Forks and feedbacks are welcome.
Hope this helps!
I developed an application that depends on a DLL file. When I debug my application, the applicationwould complain that:
"This application has failed to start because xxx.dll was not found."
So I have to copy the DLL file into the same directory as my .vcproj file.
Is there a way to set the project to look for the DLL file in (preferably) some relative path or (not preferred) some absolute path?
Similar concept to how we set include and library path in the project settings.
I mean when I debug my application (hitting F5) the above error would pop up.
Go to project properties (Alt+F7)
Under Debugging, look to the right
There's an Environment field.
Add your relative path there (relative to vcproj folder) i.e. ..\some-framework\lib by appending PATH=%PATH%;$(ProjectDir)\some-framework\lib or prepending to the path PATH=C:\some-framework\lib;%PATH%
Hit F5 (debug) again and it should work.
Go through project properties -> Reference Paths
Then add folder with DLL's
The search path that the loader uses when you call LoadLibrary() can be altered by using the SetDllDirectory() function. So you could just call this and add the path to your dependency before you load it.
See also DLL Search Order.
Another possibility would be to set the Working Directory under the debugging options to be the directory that has that DLL.
Edit: I was going to mention using a batch file to start Visual Studio (and set the PATH variable in the batch file). So then did a bit of searching and see that this exact same question was asked not long ago in this post. The answer suggests the batch file option as well as project settings that apparently may do the job (I did not test it).
In your Project properties(Right click on project, click on property button) ▶ Configuration Properties ▶ Build Events ▶ Post Build Events ▶ Command Line.
Edit and add one instruction to command line.
for example copy botan.dll from source path to location where is being executed the program.
copy /Y "$(SolutionDir)ProjectDirs\x64\Botan\lib\botan.dll" "$(TargetDir)"
I had the same problem and my problem had nothing to do with paths. One of my dll-s was written in c++ and it turnes out that if your visual studio doesn't know how to open a dll file it will say that it did not find it. What i did was locate which dll it did not find, than searched for that dll in my directories and opened it in a separate visual studio window. When trying to navigate through Solution explorer of that project, visual studio said that it cannot show what is inside and that i need some extra extensions, so that it can open those files. Surely enough, after installing the recomended extension (in my case something to do with c++) the
"This application has failed to start because xxx.dll was not found."
error miraculously dissapeared.
I know this question had been answered years ago, but for those like me who needed to change where the debugger starts the application, change the command property under Project Properties -> Debugging.