I have a website (MVC) and some other projects in the same solution.
In one of those separate projects I have some XSDs that I want copied to the bin folder of the website on build.
I have specified the XSDs as content and copy always but they only get copied to that project's bin/debug folder not the bin of the website.
Is there any way of having them copied to the website's bin?
Is it possible to write a post-build script to deploy these files to the project flagged as StartUp in a solution?
The bigger picture - I just want to validate some generated xmls against these XSDs, but dont want to have these XSDs as content in every solution that uses this project.
Cannot use the XSDs as embedded resources because of import statements in the XSDs referencing each other.
I have flagged these XSDs as content and copy always to output folder.
For some reason this doesn't copy them when building/publish the solution on my local machine through VS, but it works when running a TFS build.
Good enough I guess...
Related
We have a VS 2017 Solution with a main web project in it. We also have 3 other web projects - these are modules that depend on the main web project. However, the main web project doesn't reference or known anything about that modules. When the solution builds the modules copy their output to the bin folder of the primary web project. The modules must depend on the latest version of the main project, so it needs to build main first and then the modules. This all works great locally - the site loads the modules work etc.
We are currently using Octopus and its Octopack step runs after Solution and gets all the files. We are trying to move to just using VSTS and are having problems getting the module files into a standard web deploy zip.
When MSBbuild runs on Solution it creates a zip file per web project. The zip file for the main project doesn't contain the Dll files for the modules (even though they are in bin folder). Therefore when we deploy via VSTS site is missing the modules. How do we tell MSBuild to create a single webdeploy package for the solution including the built modules?
The MSBuild command is basically the out the box one from VSTS:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:PackageLocation="C:\temp\web.zip"
As far as I can see MsBuild is making the webdeploy zip before the other solution items copy their contents into the bin folder. MSBuild is a bit of a mystery to me at the best of times.
Largely this is just a case of making MSBuild include extra files that aren't part of the project. The pack web project publish only cares about files that are included in the project.
I updated main web project Csproj file following the guide in this question How do you include additional files using VS2010 web deployment packages?. I ran MSBuild once to build Solution so module dll files were available and I then ran MSBuild again with main web project to create the WebDeploy output with the extra included files.
Not sure this is the best way - seems a bit convoluted just to add some files but it works.
I have a VS solution with multiple projects, and I'm using Nuget to obtain external references. However, it's important that the package files for one project Not be in the same folder as the packages for the rest of the solution. As such I would like to put them into their own, seperate folder.
It would also be acceptable if all of the packages went into one folder, and then only the ones used by other projects were copied into the folder that they need them to be in. But I don't know of any way to achieve this behavior either.
If it helps, the specific scenario is a Unity project referencing a standard .NET class library project. The solution contains the .csproj file for the library DLL and also the ones generate by Unity. Because unity regenerates those project files every time the Unity project is changed, any packages to be used by those projects need to be inside the Unity project's Assets/ folder, or else the references won't be added to the generated .csproj files.
However, ALL dlls contained anywhere in the Assets/ folder are added to the generated projects, unless manually marked as not to include on a per-file basis. Which is why I don't want the packages referenced by the Library project to end up in that folder, as manually going through and marking every single .dll in every single package not to be used by the Unity project will become very tedious very fast. Especially since some packages download numerous dlls for many different versions of .net.
I have a custom MSBuild script (e.g. WpfResources.proj), in which I scan through multiple folders for *.resx files anc build .NET satellite resource dlls using the AL task. The output of this WpfResources.proj contain multiple *.resources.dll under different folders (corresponding to different projects which will need these resource dlls).
The example output folder structure is shown as following:
WpfResources
Bin
Project1
zh-CN
Project1.resources.dll
es-ES
Project1.resources.dll
...
Project2
zh-CN
Project2.resources.dll
es-ES
Project2.resources.dll
...
This WpfResources.proj can be built correctly by MSBuild.exe. However if I run it in TFS 2010 build (i.e. create a build definition and refers to the WpfResources.proj to build), it failed to copy all those resource dlls into the drop location. Actually it outputs nothing to the drop location even though on the actual build PC, the output is fine.
How can TFS 2010 build handle custom MSBuild scripts which output multiple files under multiple folders? Is there something missing in my WpfResources.proj which the Team build will consider as outputs of this MSBuild project?
On a build system, TFS handles the binary output directory and the copying of its output to a drop folder a bit special. It generates a central output directory for all output files.
I would imagine that your MSBuild project does output the standard way as if it were on a development system, with output bins under the project folder structure. TFS will not copy them to the drop folder, because by default, it only copies the binaries it produced under the central output folder.
For our systems, we solved the issue (that also goes for building VS Setup projects) but having a manual copy action embedded in the build template that copies the MSBuild output to either the centralized bin output folder, or directly towards the drop folder location.
For adding such a custom action, please see the fine TFS2010 customization blog of Ewald Hofman at: http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx.
Hope that helps.
Im setting up a svn repository and wondering where i should put the dll files.
What Ive currently done is put them in the /bin/debug folder and then link them in my project file in visual studio.
is this the way to do it?
I presume you are asking about third party dll files, because the output (exe/dll) files generated by the project are better left unmanaged by SVN, because they are regenerated on each and every build.
What I usualy do is create a Lib folder, that is on the top level of my source tree, and put all needed references there, usually in additional folder divided by tool or by functionality (logging, emailing, apis, etc, etc...)
You should not put anything from the bin/Debug or bin/Release in your source control. If you do that, you will lose them when you clean your solution or your projects.
What you have to do is create a folder, within the solution folder for example, and reference the dlls in your projects. Any third-party dll that is in the references of a project will be copied to the bin/Debug or bin/Release folder when the project is compiled.
We typically have a seperate folder called dlls or something where we keep all 3rd party dlls/assemblies
Dlls are only needed at runtime. For a quick fix, you may copy your dlls in the Debug folder where your .exe file is. This Debug folder is at the same level as the solution .sln file in Visual Studio. Which thing you will have to do each time you start a new project... Debug folder
A better solution would be to copy all third party dlls, plus all the corresponding .h and .lib files, in 2 folders, say C:\dev\include and C:\dev\lib, and then add these 2 folders to your path environment variable once for all. This way, you'll be able to access them from all your projects, without having to copy them over and over.
Now, if you want someone to be able to run your project on another computer, you'll need to copy all needed .h, .lib and .dll files in your project in a separate folders that you create, say include and lib again, in your project directory where your own program files are, as mentioned in the previous posts. Project folder
PS. Sorry, it would not let me upload the 2 screenshots, so click on links.
I typically put it in a Lib folder within my Visual Studio project solution folder. I would also create sub folders all the way to indicate whether the dll is for a 32 bit or 64 bit build and also which version of Visual Studio was used to build it. So something like this: Lib\WIN32\VC2015\ . Then in the Project Properties of the project, under the Debugging Configuration Property, I set Environment to
PATH=$(SolutionDir)Lib\WIN32\VC2015;%PATH%
By doing this, I can have separate dll folders for different project configurations if I want to and also the dll files are in a good place to check into source control as well.
If a VS2008 project is created initially with a web app project, and class projects are added, and the structure is like this:
Parent Folder
Web App Project Folder - (solution Files in this folder)
Class Project 1
Class Project 2
...
do you see any problems with moving the .sln and .suo files to the parent directory?
Parent Folder - (solution Files in this folder)
Web App Project Folder
Class Project 1
Class Project 2
...
I adjusted the .sln project directories and the solution seems to be working fine, but I'm wondering if this action will break something I didn't anticipate.
Only the project files determine their build outputs - solutions only link projects together into a logical entity, so that they can be loaded at the same time in a Visual Studio instance. If the projects are still the same, nothing's broken.
And the .suo file can be safely deleted. It's a user-specific file that simply retains a particular user's options for a solution. It contains nothing that's important to projects, build settings etc.
You can open your .sln file with whatever editor you'd like, even notepad, and see that it contains only references to your project files in it, you can modify it so that the relative paths to your project files in it match your layout. VS wouldn't have anything against it.
All build settings are stored in project files, so you don't loose any configuration changes you've done in your projects.