Related
I have a visual studio solution.
I have many projects in the solution.
There is one main project which acts as the start up and uses other projects.
There is one project say "ProjectX". Its reference is added to main project.
The ProjectX references another .NET dll (say abc.dll) that isn't part of the solution.
Now this abc.dll should be copied to bin/debug folder of main project, but it isn't getting copied there. Why is it not getting copied, any known reasons ?
I found that if ProjectX referenced the abc.dll but didn't directly use any of the types DEFINED in abc.dll, then abc.dll would NOT be copied to the main output folder. (It would be copied to the ProjectX output folder, to make it extra-confusing.)
So, if you're not explicitly using any of the types from abc.dll anywhere in ProjectX, then put a dummy declaration somewhere in one of the files in ProjectX.
AbcDll.AnyClass dummy006; // this will be enough to cause the DLL to be copied
You don't need to do this for every class -- just once will be enough to make the DLL copy and everything work as expected.
Addendum: Note that this may work for debug mode, but NOT for release. See #nvirth's answer for details.
Just a sidenote to Overlord Zurg's answer.
I've added the dummy reference this way, and it worked in Debug mode:
public class DummyClass
{
private static void Dummy()
{
var dummy = typeof(AbcDll.AnyClass);
}
}
But in Release mode, the dependent dll still did not get copied.
This worked however:
public class DummyClass
{
private static void Dummy()
{
Action<Type> noop = _ => {};
var dummy = typeof(AbcDll.AnyClass);
noop(dummy);
}
}
This infomation actually costed me hours to figure out, so I thought I share it.
Yes, you'll need to set Copy Local to true. However, I'm pretty sure you'll also need to reference that assembly from the main project and set Copy Local to true as well - it doesn't just get copied from a dependent assembly.
You can get to the Copy Local property by clicking on the assembly under References and pressing F4.
It looks slick when you make it an assembly attribute
[AttributeUsage(AttributeTargets.Assembly)]
public class ForceAssemblyReference: Attribute
{
public ForceAssemblyReference(Type forcedType)
{
//not sure if these two lines are required since
//the type is passed to constructor as parameter,
//thus effectively being used
Action<Type> noop = _ => { };
noop(forcedType);
}
}
The usage will be:
[assembly: ForceAssemblyReference(typeof(AbcDll.AnyClass))]
Ran into this same issue. Background info: before building, I had added a new Project X to the solution. Project Y depended on Project X and Project A, B, C depended on Project Y.
Build errors were that Project A, B, C, Y, and X dlls could not be found.
Root cause was that newly created Project X targeted .NET 4.5 while the rest of the solution projects targeted .NET 4.5.1. Project X didn't build causing the rest of the Projects to not build either.
Make sure any newly added Projects target the same .NET version as the rest of the solution.
Not sure if this helps but for me, many times I reference a DLL (which automatically adds it to the bin folder of course). However that DLL might need additional DLLs (depending on what functions I'm using). I do NOT want to reference those in my Project because they just simply need to end up in the same folder as the DLL I am actually using.
I accomplish this in Visual Studio by "Adding an existing file". You should be able to add it anywhere except the Add_data folder. personally I just add it to the root.
Then change the properties of that file to ...
Build Action = None (having this set to something like Content actually copies the "root" version to the root, plus a copy in the Bin).
Copy to output folder = Copy if Newer (Basically puts it in the BIN folder only if it is missing, but doesn't do it after that)
When I publish.. my added DLL's only exists in the BIN folder and nowhere else in the Publish location (which is what I want).
You could also check to make sure the DLLs you're looking for aren't included in the GAC. I believe Visual Studio is being smart about not copying those files if it already exists in the GAC on the build machine.
I recently ran in this situation where I'd been testing an SSIS package that needed assemblies to exist in the GAC. I'd since forgotten that and was wondering why those DLLs weren't coming out during a build.
To check what's in the GAC (from a Visual Studio Developer Command Prompt):
gacutil -l
Or output to a file to make it easier to read:
gacutil -l > output.txt
notepad.exe output.txt
To remove an assembly:
gacutil -u MyProjectAssemblyName
I should also note, that once I removed the files from the GAC they were correctly output in the \bin directory after a build (Even for assemblies that were not directly referenced in the root project). This was on Visual Studio 2013 Update 5.
If you right Click the referenced assembly, you will see a property called Copy Local. If Copy Local is set to true, then the assembly should be included in the bin. However, there seams to be a problem with Visual studio, that sometimes it does not include the referenced dll in the bin folder... this is the workaround that worked for me:
In my case, it was the stupidest thing, caused by a default behavior of TFS/VS that I disagree with.
Since adding the dll as a reference to the main project did not work, I decided to add it as an "Existing Item", with Copy Local = Always. Even then the file was not there.
Turns out that, even though the file is present on the VS Solution and everything compiled both locally and on the server, VS/TFS did not add actually add the file to source control. It was not included on the "Pending Changes" at all. I had to manually go to the Source Control Explorer and explicitly click on the "Add items to folder" icon.
Stupid because I've been developing for 15 years in VS. I've run into this before, I just did not remember and somehow I missed it because everything still compiled because of the file being a regular reference, but the file that was added as Existing Item was not being copied because it did not exist on the source control server.
I hope this saves someone some time, since I lost 2 days of my life to this.
Issue:
Encountered with a similar issue for a NuGet package DLL (Newtonsoft.json.dll) where the build output doesn't include the referenced DLL. But the compilation goes thru fine.
Fix:
Go through your projects in a text editor and look for references with "Private" tags in them. Like True or False. “Private” is a synonym for “Copy Local.” Somewhere in the actions, MSBuild is taking to locate dependencies, it’s finding your dependency somewhere else and deciding not to copy it.
So, go through each .csproj/.vbproj file and remove the tags manually. Rebuild, and everything works in both Visual Studio and MSBuild. Once you’ve got that working, you can go back in and update the to where you think they need to be.
Reference:
https://www.paraesthesia.com/archive/2008/02/13/what-to-do-if-copy-local-works-in-vs-but.aspx/
Make sure that the dependent DLL used by you does not have target .NET Framework higher than the target .NET framework of your project's Application.
You can check this by selecting your project, then press ALT+ENTER, then select Application from left side and then select Target Framework of your project.
Suppose,
dependent DLL Target Framework = 4.0 and
Application DLL Target Framework = 3.5 then change this to 4.0
Thank you!
This is a slight tweak on nvirth's example
internal class DummyClass
{
private static void Dummy()
{
Noop(typeof(AbcDll.AnyClass));
}
private static void Noop(Type _) { }
}
I would do add it to Postbuild events to copy necessary libraries to the output directories. Something like XCopy pathtolibraries targetdirectory
You can find them on project properties -> Build Events.
TLDR; Visual Studio 2019 may simply need a restart.
I encountered this situation using projects based on Microsoft.NET.Sdk project.
<Project Sdk="Microsoft.NET.Sdk">
Specifically:
Project1: targets .netstandard2.1
references Microsoft.Extensions.Logging.Console via Nuget
Project2: targets .netstandard2.1
references Project1 via a Project reference
Project2Tests: targets .netcoreapp3.1
references Project2 via a Project reference
At test execution, I received the error messaging indicating that Microsoft.Extensions.Logging.Console could not be found, and it was indeed not in the output directory.
I decided to work around the issue by adding Microsoft.Extensions.Logging.Console to Project2, only to discover that Visual Studio's Nuget Manager did not list Microsoft.Extensions.Logging.Console as installed in Project1, despite it's presence in the Project1.csproj file.
A simple shut down and restart of Visual Studio resolved the problem without the need to add an extra reference. Perhaps this will save someone 45 minutes of lost productivity :-)
You may set both the main project and ProjectX's build output path to the same folder, then you can get all the dlls you need in that folder.
NO NEED FOR DUMMY IN CODE
Just :
add a Reference to the Executeable Project
or/and ensure that the reference in the executeable project has "Copy Local" set to TRUE (which was my "fault") is seems that this "overwrote" the setting in the base referenced library-project...
Other than the common ones above, I had a multi-project solution to publish. Apparently some files target different frameworks.
So my solution: Properties > Specific Version (False)
Add the DLL as an existing item to one of the projects and it should be sorted
VS2019 V16.6.3
For me the problem was somehow the main .proj file ended up with an entry like this for the project whose DLL wasn't getting copied to the parent project bin folder:
<ProjectReference Include="Project B.csproj">
<Project>{blah blah}</Project>
<Name>Project B</Name>
<Private>True</Private>
</ProjectReference>
I manually deleted the line <Private>True</Private> and the DLL was then copied to the main project bin folder on every build of the main project.
If you go to the reference of the problem project in the references folder of the main project, click it and view properties there is a "Copy Local" setting. The private tag equates to this setting, but for me for some reason changing copy local had no effect on the private tag in the .proj file.
Annoyingly I didn't change the copy local value for the reference, no idea how it got set that way and another day wasted tracking down a stupid problem with VS.
Thanks to all the other answers that helped zone me in on the cause.
HTH
I had a similar issue in which a DLL I had included in the project as content and 'Copy always' set, wasn't being copied to the bin folder. I solved this by adding a dependentAssembly reference to the DLL in the app.config.
I've started an open source MVC4 project that is using some other open source project as a dependency. I've forked the other project and will be modifying it according to my needs. The problem I'm facing is how to keep these projects depending on each other, but maintained separately. Yet people who git pull my project, would get the dependency project as well?
I can slam all the related code from other project into my repository, but this way I won't be able to contribute to a fork of dependent project. I'll just become a part of my repository. Not really want to do that.
I can maintain other project completely separately and copy *.dll files into my project. And commit dependent dll files into git. This is nice, but I loose ability to develop two projects at the same time, along with stepping into dependent code on debug (well, maybe not if copy *.pdb files along)
Similar to point 2, I can build nuget packages from dependent project and add them to my main project - again, can't really develop both projects at the same time, need to switch contexts.
With some magic have a solution file that combines projects from my repository and from dependent repository. On every build, copy dependent dll files to /lib folder and commit them. This way I don't need to switch contexts between separate projects. But the drawback is when other contributors git pull my project, they don't get dependent project, and solution files will likely be broken for them, because it'll reference project that is not in the repo.
How do you organise your code in this case?
Usually I use nuget for all my dependencies. When I fork a project I will deploy it on nuget and also on symbol source. In this way you can step inside the dependency source without problems.
For more information on symbol source and nuget see also:
Creating and Publishing a Symbol Package.
To enable symbol source debug see http://www.symbolsource.org/Public/Home/VisualStudio.
You must also remember to enable Nuget package restore.
With this solution you can't modify source code but at least you can debug it.
I use something similar in concept to CMake, but entirely within Visual Studio. There's the relatively unknown feature of property files, which can be included by solutions. This allows you to create a file containing only paths to dependencies, include the libraries you can and set relative paths, and then require people to set the appropriate paths for the other dependencies you can't/don't want to include.
With a little bit of work, it comes out fairly clean, and is super easy to automate through TeamCity and other similar tools (each build agent can set the variables to indicate where it keeps dependencies).
For small dependencies and ones that have been tweaked to work with my project, I keep an archive or the loose files in the repository, and use the properties file to reference those. Others have instructions on where to find them and how to edit the paths.
If you're interested in such an approach, I can go into some more detail. It took a bit of work to figure out, as property files aren't super well documented, but is working pretty neatly.
In case you are not creating circular dependencies, following is an idea:
add a new Class Library project with a unique name, say ClassLibrary1, to the solution
in the Build page of its project settings, config Output path to application output path
in the Build Events page, add the following line to Post-build event command line block:
del "$(TargetPath)"
repeat step 1 to 3 but giving another name, say ClassLibrary2, and config Output path to the source path of ClassLibrary1
set Project Dependancies of ClassLibrary1, check on ClassLibrary2
add all other project as project reference to ClassLibrary2, leave Copy Local with default value true
build ClassLibrary2 once, and all DLLs now are in the source path of ClassLibrary1
add them to references of ClassLibrary1 and leave Copy Local with default value true
set Project Dependancies of application and all other projects which are not cause circular dependencies, check on ClassLibrary1
add references of other projects, from the path the DLLs were put in ClassLibrary1
set Copy Local of all these added DLLs in other projects to false
Thus, the project ClassLibrary1 be a central control of the external libraries of your solution. Each time you Rebuild Solution(or just build the application), ClassLibrary1 copies the latest DLLs add to its references to the application output folder, and deletes the DLL it generated itself named ClassLibrary1.DLL. The application and dependencies at either compile time or runtime would use the same version of DLLs, you don't need to do extra deploying or check each deployments.
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++)
I have a big project with many subprojects.
(as mentioned in the drawing)
Both WebSiteA and WebSiteB has referenced to both DLL projects.
however when I change the dll's - I need to update each bin in each webSite.
I Don't want that.
I know I can put them in GAC but I was told not to (don't ask me why please.)
Is there any solution like :
so when I update any dll - I put it only at one place ? (and so the dll's won't be at each site's bin)
You can make a trick with the .refresh file reference, but not tested on the live server.
First place your common dll, on a common directory.
Second on each bin, place the *.refresh file together with the dll, that says inside from where to update the dll if a new version is found.
and so you have inside the Bins something like:
mySuperModule.dll
mySuperModule.dll.refresh
and inside the mySuperModule.dll.refresh the location of the module that need to check for update ->
d:\Dlls\mySuperModule.dll
where d:\dlls are the common place for the dlls that search for new updates.
At the end you only update the common directory dlls, and you left the projects make the rest automatic.
The whole point of the GAC is to provide that functionality, if you don't use that then you can't share the DLLs in the way you want. This is due to how sites are secured and separated from each other.
Hereis the situation:
I have a folder that contains library DLLs, which are not built as part of my solution - lets say it is .\libs.
I add references to these DLLs. I then build. Everything is fine.
If I then delete the libs folder and rebuild my solution, the compilation still succeeds! Weird - I would have expected compilation errors since the library dlls are not there!
But looking at the reference properties in Visual studio, I see that the reference path has been changed from .\libs\foo.dll to myproject\bin\Debug\foo.dll. So it is picking up the referenced DLL from its old build output.
If I open myproject.csproj in a text editor, I see that the HintPath of the reference is still .\libs\foo.dll. If I re-create the libs folder, visual studio still uses myproject\bin\Debug\foo.dll (it does not revert to the actual DLL I want!)
Is this expected behaviour?
Is there a way to stop this behaviour because it is causing me problems - especially when I want to rebuild myproject with different versions of the libs: half the time I find that I am using a different version than what I wanted.
This is not magic. Your DLL's Copy Local Property is probably set to true, that's all.
Setting it to false will get you the desired behaviour.