I have Visual Studio 2019.
I know we can build one project with multiple configurations, and have a dll per configuration, for example we can have one dll for the Debug configuration of our project and we can have one dll for the Release configuration of our project.
But my question is how to have multiple dlls for one project based on DefineConstants, for example one dll when we <DefineConstants>ML_HOOSHANG</DefineConstants> and have another dll for this project without define this constant?
Another question is how to package this project with hold all of these dlls per definition of our define constants?
Another question is, can I force Visual Studio (msbuild) to generate all dlls per build request?
Is UsingTask useful for this purpose? or not?
Is there anyway to change DefineConstants per UsingTask?
How to create multiple assets (dll) for one project with msbuild
depend on Constants value?
You may get some hint from this issue. Batch build in VS2019 is something that can help for your issue.
Possible direction:
Create one new project named TestBatchBuild. Right click Solution=>Configuration Manager and create new project configuration NewDebug and NewRelease.(Copy settings from Debug and Release)
Now right click solution=>batch build we can see:
Then let's edit the project file(xx.csproj) and we can find four PropertyGroup. Add <DefineConstants>ML_HOOSHANG</DefineConstants> to NewDebug and NewRelease PropertyGroup and Save ALL.
Now building with NewDebug equals to build with Debug+DefineConstants. And building with NewRelease equals to build with Release+DefineConstants. Now let's go batch build page, we can build four assemblies at one time. (Debug+nodef..., Debug+def...,Release+nodef...,Release+def...). Hope all above helps.
I have a solution in visual studio where one project (.csproj) is set to create an exe.
I would need to create a duplicate copy of this project so that I can name it something different and change the icon for it. (All of the rest of the projects can stay the same)
I am using conditional compilation symbols for that project, but I don't want to create a whole separate solution configuration because that requires expensive rebuilding of the entire solution.
In Visual Studio under Build -> Configuration Manager, you can create a new configuration for your project and clone it from your release build, then in your project properties you can customize it.
For the icon, you'll want to refer to Set a different ApplicationIcon for each build configuration
Create a copy of the project on disk (outside Visual Studio) and add the copied project to the solution. Then you can modify output assembly name, icon. etc..
However better practice would be to perform the necessary operations as postbuild step (e.g. batch/powershell script) as you will have to keep the projects synchronized (added/renamed/removed files, references...)
Copy it somewhere else and change the assembly name and namespace may be on the project property window( right click and property)
I dont know what your trying to accompish but possible solutions:
add post build event that will copy exe / (exe ad dll-s) to another directory
if you use TFS, edit your Build so it will create copys
Cheerz,
So, as the title reads, I have a VS2010 solution with ~50 projects in it right now. If I make a change to a "top level" project that nothing references then VS still rebuilds all 50 projects. I'm running Visual Studio 2010 Ultimate without any add-ons. I am using ILMerge to consolidate all of the projects into a single file.
I have verified this by checking the time stamps of the lower level dlls and see that they are indeed rebuilt even though their code wasn't touched.
I've read all responses and comments for:
Visual Studio 2008 keeps rebuilding
Visual studio keeps building everything
Strange VS2010 build glitch occurs in my solution
Reasons for C# projects to rebuild in Visual Studio
But most of them just offer suggestions on unloading projects to speed up build times but nothing concrete as to a fix. I'm trying to figure out why VS thinks these dependent projects need to be rebuilt when they don't and fix it.
I've turned on 'Tools > Options > Projects and Solutions > Build and Run > Only build startup projects and dependencies on run' but with no effect.
Also, if I just rebuild a "mid-level" project that only has 8 (in)direct dependencies then it still builds all 8 projects even though ILMerge isn't invoked and none of the dependent projects have been modified.
Thank you everyone for any insight you may be able to provide.
Added
To test some of the suggestions I created a new WinForms project from scratch. I then created two new projects inside that solution. I copied all of the code and resources (not project file) from my two 'lowest level' projects into the two brand new projects (I did this by dropping the files and folders from Explorer onto the project in Visual Studio).
The lowest project, let's call it B, did not reference any other project. The next project, A, referenced B only. So once I added the required .NET and external assembly references to the projects then the solution would build.
I then had my new WinForm project reference A and did a full build. So the ref chain is:
WinForm -> A -> B
I then modified WinForm only and did a standard build (F6). As before, Visual Studio rebuilt all three projects.
After some systematic eleminiation of source files in project B I found that if I removed my Resources.Designer.cs and Resources.resx (and commented out the code that made use of the .Properties.Resources object of those resources) then a modification of WinForm would no longer rebuild the entire solution and would only rebuild WinForm.
Adding the Resources.resx and Resources.Designer.cs back to project B (but leaving the referenced code commented out so that nothing was making use of the resources) would re-introduce the full build behavior.
To see if perhaps my resource files were corrupted, I deleted them again and then created a new one (via Project Properties -> Resources) and re-added the same resource as before, which was a single Excel file. With this setup the full rebuild would still occur.
I then removed the single resource, but left the resource file in project B. Even with no resources added, but the resource file still in the project, the full (unneeded) rebuild would occur.
It appears that just having a resource file added to a (.NET 3.5) project will cause Visual Studio 2010 to always rebuild that project. Is this a bug or intended/expected behavior?
Thanks all again!
Open Tools - Options, select Projects and Solutions - Build and Run in tree, then set "MSBuild project build output verbosity" to Diagnostic.
This will output the reason for building a project, i.e.
Project 'ReferencedProject' is not up to date. Project item
'c:\some.xml' has 'Copy to Output Directory' attribute set to 'Copy
always'.
or
Project 'MyProject' is not up to date. Input file
'c:\ReferencedProject.dll' is modified after output file
'c:\MyProject.pdb'.
In this case the fix is to copy some.xml only if newer.
Pre and post build events can trigger build as well.
While I don't think this is a fix, it is a workaround that has worked for my situation...
I originally had about 5 projects out of 50 that contained a Resources section. These projects would always be rebuilt and thus anything that they depended on would also be rebuilt. One of those 5 projects was a "base" level library that 48 of the other projects referenced, thus 96% of my project would be rebuilt every time even if it didn't need it.
My workaround was to use dependency injection, interfaces, and a dedicated "Resources" project. Instead of having those 5 projects reference their own Resources object, I created an interface in each project that would supply the desired resources. Then, the classes that needed those resources would require that interface be passed in during their creation in the constructor (constructor injection).
I then created a separate "Resources" project that had an actual Resources section like normal. This project only contained the resources themselves, and a class for each interface that was needed to provide those resources via an interface. This project would reference every other project that had a resource dependency and implement the interface that the project needed.
Finally, in my "Top Level" project which nothing referenced (and where the exe was actually built and my composition root lives) I referenced the "Resources" project, wired up the DI, and away we went.
This means that only two projects (the "Resources" and the "Top Level") will be rebuilt every time, and if I do a partial build (Shift-F6) then they won't get rebuilt at all.
Again, not a great work around, but with 48 projects being built every time a build would take about 3 minutes, so I was losing 30 to 90 minutes a day with needless rebuilds. It took awhile to refactor, but I think it was a good investment.
Here is a simplified diagram. Note that the dependencies from Main.exe to Proj1 and Proj2 are not shown in order to reduce clutter.
With this design, I can do a build of Proj1 or Proj2 without triggering a full rebuild, since they don't have any dependencies on a Resources section. Only Main knows about the Resources implementation.
This happens when a project has a file that doesn't really exist.
The project can't determine if the file was changed (because it's not there) so it rebuilds.
Simply look at all the files in the project, and search for the one that doesn't have an expandable arrow near it.
I had the same issue in VS 2015.
What did the trick for me is:
One project was referencing itself copy in some other project bin (magic, yes). This kind of stuff could be found when switching to diagnostic build output (in build options) and then trying to build projects one by one from the top of projects hierarchy - if you see the project that rebuilds even if nothing has been changed then see it's references.
I've changed all "copy always" files in all projects to "copy if newer". Basically, in all .csproj files replace <CopyToOutputDirectory>Always</CopyToOutputDirectory>
to <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
Then I've disabled NTFS tunneling as described in this article with this powershell script:
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "MaximumTunnelEntries" -Value 0 -PropertyType "DWord"
After that I needed on rebuild and it seems working for now.
In my case the culprit was "Copy Local" setting of a referenced dll set to true and "Copy to Output Directory" setting a file set to Copy always.
For .Net Core Projects, all solutions above are not working.
I've found the solution. In case you are using Visual Studio 2019:
Build the solution twice
Turn on Tools -> Options -> Projects and Solutions -> SDK-Style Projects -> Logging Level -> Verbose
Clear the output window
Build your start project
Inspect the output window. All the string starting with FastUpToDate
You will find some project items that are making your project not up to date.
Fix these issues and try again from step 1. If your fixes are correct, you will achieve Build: 0 succeeded, 0 failed, {n} up-to-date, 0 skipped in the last string of build output.
The MSBuild team is collecting documentation about investigating build incrementality issues here:
https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed
UPDATED LINK: https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Rebuilding-when-nothing-changed.md
Based on your observations, it sounds like you have projects expressing dependencies to other projects in a way that isn't obvious. It is possible for orphaned dependencies to remain in project files without being apparent in the UI. Have you looked through a misbehaving project file after opening it in a text editor? Checked solution build dependencies?
If you're not able to spot anything, try recreating one of your projects from scratch to see if the new project exhibits the same problem. If the clean project builds correctly, you'll know that you have unwanted dependencies expressed somewhere. As far as I know, these would have to be in the project file(s) or the solution file, unless you have makefiles or other unusual build steps.
Another problem that frequently happens is when some item in your solution has a modified stamp that is in the future. This can happen if you set your clock forward, and then set your clock to the correct time. I had this happen while installing Linux.
In this case you can recursively touch all the files using git bash (yes, in Windows):
find . -exec touch {} \;
I've finally found one more culprit that I had hard time finding by increasing the build log verbosity.
In some cases, MSBuild looks for vc120.pdb in the output folder, and if this file doesn't exist, it will rebuild the entire project. This occurs even if you have disabled debug symbol generation.
The workaround here is to enable debug symbols and let this file get generated, then disable the setting again without deleting the PDB file.
I had this same problem and it turned out to be related to a couple of project that had a copy local reference to a dll in their own output directory.
The key to finding this was having diagnostic output set for the build output, but also knowing what to look for in the log. Searching for: 'not up to date' was the key.
Here is an answer from VS2010 always rebuilds solution?
This issue is solved by changing the project files, cleaning solution,
deleting all bin folders by hand, restarting Visual studio and
rebuilding everything.
I had the same issues with you.
I found that it came from some deleted files.
When I had removed the files from my project, the issues was gone.
Regards.
For this category of build problems setting MSBuild output verbosity to 'diagnostic' is indeed a necessary first step. Most of the time the stated reason for the re-builds would be enough to act upon, BUT occasionally MSBuild would erroneously claim that some files are modified and need to be copied.
If that is the case, you'd need to either disable NTFS tunneling or duplicate your output folder to a new location. Here it is in more words.
I had the problem of Visual Studio rebuilding projects when upgrading from Visual Studio 2015 to 2017 and I add this answer for the benefit of those who might experience similar problems, as it does not seem to be documented anywhere.
In my case, the problem was that all projects in the solution had the same intermediate Output path (obj). The file GeneratedInternalTypeHelper.cs gets generated by all projects containing XAML. Up to Visual Studio 2015, the build process apparently did not check for the file date of this file and thus no problem with it occurred. With VS2017 the file date of this file is checked and because a later project in the build process will overwrite it (with the same content), the earlier project will re-build, re-triggering the later build, ad infinitum.
The solution in this case is to ensure that all projects have differing intermediate output directories, which will make the problem go away.
In my case (mixed C#, C++/CLI and native C++ solution) , some C++ projects were being re-linked even if nothing had changed. I spent ages trying to work out what was happening. In the end I worked out from the "Command Line" option that the PDB output path (option /Fd) could not handle the folder setting $(IntDir). I removed that - an empty value will do the default correctly - and my issue went away.
As others have noticed, a likely reason is that CopyToOutputDirectory is set to Always. This can be fixed simultaneously in all project files by applying the powershell script below:
$folder = "C:\My\Solution\Folder"
$csvFiles = Get-ChildItem $folder *.csproj -rec
foreach ($file in $csvFiles)
{
(Get-Content $file.PSPath -Encoding UTF8 -Raw) |
Foreach-Object { $_ -replace "<CopyToOutputDirectory>Always</CopyToOutputDirectory>", "<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>" } |
Set-Content $file.PSPath -Encoding UTF8 -NoNewline
}
Files that do not exist are a problem and obviously files producing no output as well. That can happen, wenn you have a resource file in a static library. (C++)
Please can someone could explain why I get this error and what to do to fix it (or what I'm doing wrong!). The steps I have taken are
Download Source code from http://www.codeproject.com/Articles/16859/AForge-NET-open-source-framework
Opening in VS2010 shows the references cannot be found
Re-Add all 3 references from PlayingCardRecognition\bin\Release so no further warnings
When I try and build or Run I get the following message
To fix this issue, do these steps:
Right click the Project name in Solution Explorer of Visual Studio
Select Set as StartUp Project from the menu
Re-run your project
It should work!
If it did not work, be sure that you have set your start page. If your project is C# Windows Application or C# Console Application, try this:
Right click the Project name in Solution Explorer of Visual Studio
Select Properties
Select the Application tab
In the Output Type drop box
Select the correct application type of your project
Re-run your project and let me know if it won’t work.
The project type set as the Start-up project in that solution is of type ClassLibrary. DUe to that, the output is a dll not an executable and so, you cannot start it.
If this is an error then you can do this:
A quick and dirty fix for this, if that is the only csproj in the solution is to open the .csproj file in a text editor and change the value of the node <ProjectGuid> to the Guid corresponding to a WinForms C# project. (That you may obtain from a google search or by creating a new project and opening the .csproj file generated by Visual Studio to find out what the GUID for that type is). (Enjoy - not many people know about this sneaky trick)
BUT: the project might be a class library rightfully and then you should reference it in another project and use it that way.
.Exe's and .dll's are both assemblies. The key difference is that executeables define an entry point Main which can be invoked by the runtime. The error
"Class library cannot be started directly"
is due to the fact that said .dll's do not have a Main. To fix this issue, change the project type to a Windows application/Console application and define an entry point. Or, add a new project that is of type Windows application/Console application and reference said .dll.
The project is a class library. It cannot be run or debugged without an executable project (F5 doesn't work!!!). You can only build the project (Ctrl+Shift+B).
If you want to debug the code add a console application project (set it as the start up project) to the solution and add the reference to the library.
The project you downloaded is a class library. Which can't be started.
Add a new project which can be started (console app, win forms, what ever you want) and add a reference to the class library project to be able to "play with it".
And set this new project as "Startup project"
The project you've downloaded is a class library, not an executable assembly. This means you need to import that library into your own project instead of trying to run it directly.
Your project type is a class library one would suspect, add a ConsoleApplication or WindowsApplication and use that as your startup object. Reference this project and then access the code.
If you convert the WPF application to Class library for get the projects .dll file.After that convert the same project to the WPF application you get the following error.
Error:".exe does not contain a static main method suitable for an entry point".
Steps to troubleshoot:
1.Include the App.xaml file in the respective project.
2.Right Click on App.xaml file change the build action to Application Definition
3.Now Build your project
Goto the Solution properties -> on Build right side you see the startup project type. here you need to select the console appication/windows appication.
If you got this issue (got it in Visual Studio 2017 RC), and you don't get any of the things listed by Mak post from step 3 onward "4 In the Output Type drop box....", it is because you made a Class Library app when you want to create a cross platform app, so here is the solution :
1 Start a new project
2 select Visual C# and cross-platform app.
3 select cross-platform app (Xamarin and native app)
4 select blank form.
From then , right click, select as startup project and build as mentioned by Mak, and it should work.
If you can afford to start from scratch, it could do the trick as it did for me.
This could do the trick for the main issue as well, but must be adapted to your current version of Visual Studio ("Xamarin.forms portable" for visual studio 2015 for example).
Bye!
VS -> Debug -> Attach unity debugger -> double click project
Set your api project to a startup project:
Right click the api Project than choose Set as startup Project.
Just right click on the Project Solution A window pops up. Expand the common Properties. Select Start Up Project
In there on right hand side Select radio button with Single Startup Project Select your Project in there and apply.
That's it. Now save and build your project. Run the project to see the output.
_Sarath#F1
To fix this issue, do these steps:
Right click the Project name in Solution Explorer of Visual Studio
Select Set as StartUp Project from the menu
Re-run your project It should work!
I have a solution with 2 projects.
Both projects need the same 4 DLL's.
I have a lib folder with the 4 DLL's in each project.
When the solution is compiled the 4 DLL's in each lib folder are copied to the bin folder.
Now, there are 4 sets of the same 4 DLL's.
I tried putting the DLLs in the bin directory but Visual Studio threw a lot of errors to that.
Is this how it is supposed to work? Ideally I'd like only one set, two max. Not sure where I should put my DLLs to fix this.
Yes, this is how it's supposed to work.
You can adjust this process by changing the CopyLocal property on your references to false.
Set it to true on your start-up project and to false on the other one.
In each project you would reference them (right click on the project and "Add Reference"). Upon building of your solution or project, Visual Studio should automatically copy the required referenced dlls into the /bin directory for you.
As for multiple copies, since each project is typically autonomous, each one will have a set of the referenced dlls, however if Project A references Project B, and you're only using Project A (say Project B is a class library), then there should only be 6 dll's for project A.
- ProjectA/bin/Debug/projectA.dll
- ProjectA/bin/Debug/projectB.dll
- ProjectA/bin/Debug/shared1.dll
- ProjectA/bin/Debug/shared2.dll
- ProjectA/bin/Debug/shared3.dll
- ProjectA/bin/Debug/shared4.dll