I am using Webpack for my front-end, which will generate files with hashes in the filenames. Because of this, Visual Studio does not see them as included, and my publish fails.
My current flow is Publish -> Fail -> Add missing files, remove deleted ones -> Publish again.
Is it possible to just tell Visual Studio to include all files in a folder, no questions asked?
I already tried modifying the csproj like so:
<Content Include="SiteContent\**" />
But that does not work when publishing; I run the webpack tool in my pre-build script.
This worked (with modifications) for me: https://stackoverflow.com/a/9438419/1971537
The key was changing to
My situation is that after a successful build, powershell scripts move around and rename FE resources (js, css, html, vendor stuff) and given the renaming (for caching issue prevention), the filenames are never exactly the same, and the folder I think even gets axed. Changing this to afterbuild caused the files to get correctly added to the project after the build and the azure web deploy correctly picked them up.
Another hacky option I found that I played with initially just to see if my deployment was successful at all: https://msdn.microsoft.com/en-us/library/ee942158(v=vs.110).aspx#can_i_exclude_specific_files_or_folders_from_deployment
I tried the other two options for the Package/Publish Web tab (All files in this project and All files in the project folder) and this worked but with the issue of having to remove a ton of junk files just to get a couple files I wanted.
Hope this helps, I didn't figure anything out on my own but I eventually scraped it together. Go upvote the guy I linked first for his reply.
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.
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'm trying to split out my web resources, images/JS/CSS into another project within my Visual Studio solution so that I can share this across all projects.
I've tried setting this up as per link below
How do you share scripts among multiple projects in one solution?
However I keep on getting
Web resource '/Scripts/myscript.js' was not found.
I'm using "add as link" to link to resources from different project but they don't see to get copied over on build.
Thanks
This is a better way of doing it.
Using information from
Copy file(s) from one project to another using post build event...VS2010
and
http://greenicicleblog.com/2010/12/01/link-whole-directories-into-visual-studio-projects/#comments
I created a folder called WebAssets along side my project. I copied all my scripts, css and images to this folder.
I then added
<Content Include="..\WebAssets\**\*.*">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
</Content>
to my csproj file
This worked when I published the site, but not after a build. The local webserver kept on complain about missing files.
So I added a post build event to project, like so.
<PropertyGroup>
<PostBuildEvent>xcopy /S /Y "$(SolutionDir)WebAssets" "$(ProjectDir)" </PostBuildEvent>
</PropertyGroup>
This copied all the files from the WebAssets folder to the correct location.
This example shoes the best way I have come up with so far
http://www.codeproject.com/Articles/12997/WebResource-ASP-NET-2-0-explained
However I'm not that keen on it because it means that I have to create many manual entries in the AssemblyInfo.cs file and then modify css and js to point images. Like so
<img src='<%=WebResource("MyWebResourceProj.MyResources.Test.gif")%>'>
I'm using this command to build and deploy my site:
MSBuild myprj.sln
/P:Configuration=Debug
/P:DeployOnBuild=True
/P:MsDeployServiceUrl=http://myserver/MsDeployAgentService
/P:MSDeployPublishMethod=RemoteAgent
/P:DeployTarget=MSDeployPublish
/P:UserName=foo
/P:Password=bar
/P:DeployIisAppPath="Default Web Site\MyApp"
It works great, except I think I want to exclude a certain data file, say, ~/App_Data/data.xml. I don't want data.xml in my project since it's generated by the app or setup by the user (e.g. by renaming and configuring data.xml.orig to data.xml).
So what to do? Can I simply exclude it from MSDeploy or should I be handling this another way?
The files that get published are the build outputs from your project; this includes your DLL and any files with Build Action set to Content. If you set the Build Action to None (click the file in VS, view it's properties), it should get excluded automatically.
If you want to exclude the contents of the App_Data folder entirely, there's an option in the project properties, on the Package/Publish Web tab.
If I got you right, you should add /p:SkipExtraFilesOnServer=True to your command line.
This would leave all extra files on destination, which could be a flaw in some scenarios
If you want to skip only some folders (which could be required, if you do not want to garbage your server a lot, while still keeping some folders intact) - you could use solution from this question:
MSDeploy skip rules when using MSBuild PublishProfile with Visual Studio 2012
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?