We Keep Coding

Copy file from one folder to root directory

I have 2 folders named CONFIG1 and CONFIG2 in a Xamarin android project.
Each have one one file(json files) in respective folder.
But there is a task during compiling which looks for those specific file(only one) in
root directory of project.
So for the solution I want to copy the file during project build in the root directory by editing the project file.
I have tried with Copytooutputdirectory and copytopublishdirectory,but none of them working..
Please help..

You could do a pre-build task. I can't speak to the reliability of the pre-build tasks in Xamarin projects. Back in the day, they weren't stable. Maybe now they are.
Here's a picture of the Build Tasks tab (of the project's properties) in Visual Studio 2017, with the "Edit Post Build" dialog open. Basically, the pre- and post-build steps are mechanically identical. They run programs in the command shell of your operating system. The "syntax" is just the batch language of the OS. In Windows, for example, you might run a bunch of xcopy commands to move things around.
There's a preprocessor that does variable replacement before running your script...those are what are shown in the "Macros" section...along with their current values. The example passes the value of the $(TargetPath) to the update_agent.bat, which is a batch file stored in the root of our solution. There are a lot of variables to choose from...as I've attempted to show in the dialog box.
There are downsides to pre- and post-build steps. They'll resolve differently on different machines...but if you refer to files outside the solution, they may not be on every developer's machine in the same place...and the step will quietly fail.
Also, they're not portable between operating systems. I'm not even sure if VS offers pre- and post-build steps on the Mac OS version of Visual Studio.
These downsides are why there are a number of directives supported by the .CSPROJ
So, while this is an answer, I doubt it's the answer unless somebody has a better suggestion. It might get you past your immediate needs, however.
Edit
MsBuild.exe is the program that's actually processing your .csproj...and you can put MsBuild directives directly in your project. These directives can use the same set of replaceable variables that are in that pre/post build dialog. Might be a better way to go at it. Potentially more portable.
<Target Name="CopyFiles">
<Copy
SourceFiles="#(MySourceFiles)"
DestinationFolder="c:\MyProject\Destination"
/>
</Target>
Here's the Copy task from the MsBuild reference.

Is it possible to change the default Release build configuration properties in Visual Studio 2012?

When a new C# project is created, two build configurations are added to the respective csproj file - Debug and Release.
My problem is that the Release build configuration does not include the full debug information by default. I know the default is reasonable for the Release build, but in my particular case I want to change it to full debug info.
Is it possible to tweak the Visual Studio 2012 in such a way that new projects have their Release build with full debug info?

There is a very ugly way to do it:
The default project templates are stored in $(VSINSTALLDIR)\Common7\IDE\ProjectTemplates\CSharp\Windows\1033\ and you can modify them, with appropriate administrator permissions, to include whatever you'd like. This includes modifying the defaults for the debug configuration to remove the DEBUG define and to set the 'optimize' flag.
Note that making this kind of modification is global and will affect all new projects for all users on the machine. It's probably not a great idea, and I'd strongly suggest just remembering to adjust the properties of new projects as you need to, or to create a custom template.
It's ugly, but it seems to work fine in my cursory tests.

There is a solution for C++ projects, however I am afraid it is not applicable to C#:
Use a Property Manager (View / Property Manager). You can edit a property sheet called Microsoft.Cpp.Win32.user. This property sheet is used by all projects (both Debug and Release configurations). If you set your debugging requirements there, you will do no harm do Debug, as it already includes it anyway and cause Release to include it as you want.

Built with optimizations enabled or without debug information

I'm currently trying to find out why my InjectableAttributes never get to the filter part.
Therefor I linked in the source project directly so I could easily put breakpoints etc.
When I build however I get the following message:
The following module was built either with optimizations enabled or without debug information:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\[a bunch of randomly named directories]\assembly\[more random names]\MvcTurbine.Web.DLL]
To debug this module, change its project build configuration to Debug mode. To suppress this message, disable the 'Warn if no user code on launch' debugger option.
I checked the project's properties. It's configuration is set to "Active(Debug)" and the "Optimize code" check box is unchecked.
UPDATE
I checked again if I didn't by accident include the file rather then the project, but the references seem correct.
Just to be sure I also removed all existing bins so that all libraries are definitely rebuild somewhere, but to no avail.
UPDATE
In the advanced Build window the Debug output is set to Full and all options are identical to projects that are building debug info.
The config manager shows that the project is being built and has the exact same settings as all the other options.
UPDATE
In the Debug->Windows-Modules window the symbol status for the turbine library is PDB file does not match image I removed all corresponding pdb files on my entire system to make sure it gets re-generated, but to no avail.
To make sure I also searched for the dll on my entire system and removed them. Nothing.
What can be preventing VS from creating debug information?

I've just experienced the same problem this morning, using VS2010. I solved it by deleting all the build artefacts, e.g. executables, libraries, PDBs, etc. This was in \bin\Debug, \bin\Release, \obj\Debug, and \obj\Release (including sub-folders). Then I recompiled the debug configuration, and was back in business.

Check that debug info is being generated for the project. You can do this by opening the Build tab on the Project Properties page and clicking the "Advanced..." button. Check the "Debug Info" setting. See this MSDN article for an explanation of what each option means.
If that doesn't solve it, check that the MvcTurbine project is actually being built (Build -> Configuration Manager).

It sounds like you've referenced the MvcTurbine.Web.DLL file rather than the MvcTurbine project. Try removing the reference and re-adding it as a project reference.
Update Are you sure the DLL isn't coming from the GAC? Do Debug->Windows->Modules when the app is running and check the Path column.

VS2008 - Outputting a different file name for Debug/Release configurations

When building a C# application with Visual Studio 2008, is it possible to set a different output filename per configuration?
e.g.
MyApp_Debug.exe
MyApp_Release.exe
I tried a post-build step to rename the file by appending the current configuration, but that seems a scrappy approach. Plus it meant that Visual Studio could no longer find the file when pressing F5 to start debugging.

You can achieve this by editing your project file by hand. Locate the <AssemblyName> node and add a conditional attribute to it:
<AssemblyName Condition="'$(Configuration)'=='Debug'">MyApp_Debug.exe</AssemblyName>
<AssemblyName Condition="'$(Configuration)'=='Release'">MyApp_Release.exe</AssemblyName>
You'll have to duplicate it also to add another conditional attribute for the release version.
Whilst it is possible, it may cause problems. There is an AssemblyConfiguration attribute that can be applied to your assembly. In AssemblyInfo.cs, put:
#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#else
[assembly: AssemblyConfiguration("Release")]
#endif
This will add a property to your compiled assembly that will tell you which build configuration your application was built using.

As adrianbanks mentioned, you can edit your .csproj file by hand to accomplish this.
I would, however reccomend the simpler form of:
<AssemblyName>MyApp_$(Configuration).exe</AssemblyName>
If you ever edit the properties of this project however, this change will very likely be lost. It's something you will have to manually stay on top of, as it's not going to be a supported setup.
To manually edit your project definition, right click the project in Visual Studio, and select "Unload", then right click the unloaded project, and select "Edit" and it will open the XML definition for you.

I'm sure there is, however in my experience having different filenames for debug / release configurations is a bad idea as it can cause all sorts of problems (very much like the issue VS has when it tries to execute the renamed app)
Why not simply indicate whether or not its debug / release in the Assembly attributes (for example in the comments)

Breakpoint not hooked up when debugging in VS.Net 2005

Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the running version and therefore there's a mismatch that causes the breakpoint to be disconnected.
Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.
Added Note:
This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.

Maybe this suggestion might help:
While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
Look for your project's DLL, and check the Symbol Status for it.
If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
I've found that it's sometimes necessary to:
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.

http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/

In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.

Is the build configuration set to Release?
Do you have a reference to an external DLL where the breakpoint is set?

Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?
If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.
Again, the above only applies to .NET + COM Interop DLLs.

I've had a similar problem in the past.
It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.
Read the post here and the comments to resolve it.

AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.
Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.

Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).

Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.

In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.
This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]

Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?

Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?