I have a C# project that I need to change its product name upon compiling. I used the prebuild event to change it in the AssemblyInfo.cs but a few times Visual Studio doesn't get this change and compiles it with the previous product name. So i prefer to change it after compiling from another executable (all in C#).
Once the assembly is compiled, you can't (or at least shouldn't) change that information. It's compiled into a resource file inside the assembly that's not designed to be changed.
Visual Studio should always pull that information in, because it's part of the code. If it's not, that may be a sign of a bigger problem, because Visual Studio is not compiling the code you expect to be compiled, and there may be rogue versions of other code files being included as well. Try doing a complete Rebuild Solution, and make sure that the product name is then correct; if not, move the code to a different machine and compile it there, just to make sure it's not pulling in files from somewhere else on your machine for some reason.
Related
In Visual Studio when I "build" my project, does that mean that I "compiled" the source code to machine code?
If so, why not call it "Compile"?
As said by #pm100, Building does many things apart from compiling, the compiler at first compiles the code from C# to byte code (not to machine language in C# case). Here you get multiple pieces of compiled code, these pieces are not related to each other.
Here comes the role of linker, it links the multiple pieces (they are also called objects). Now the files knows how communicate and use the code from each other.
Now Visual Studio may do something else, like calling post-build hooks, copy the files to the output directory, etc.
I have a C# WinForms project, which I am working on in Visual Studio 2017 (although it was originally created in the 2015 version).
I don't recall having done anything special, but it has added a file called .dtbcache, that it wants to add to git. The file has no extension, and a Google search doesn't show any results.
The file is located in ..\repos\myprject\.vs\MyProject\DesignTimeBuild. Which means that the "dtb" part of the file name probably means design time build, but that doesn't really make it that much better.
Can I delete it or add it to .gitignore? I would prefer not to include it in our git repository, unless it is required.
Short answer: You can safely exclude it from your Git repo.
Long answer:
You're right that dtb stands for Design Time Build. This is a file automatically created by VS2017, with a bit more information here and here (links to a blog from someone working on the Visual Studio project system). In summary, it's Visual Studio more or less extrapolating what files will be produced in order to make sure Intellisense is fully available as intended.
From the linked articles, one of the purposes of this is to make sure Visual Studio has an answer in certain cases:
Given an assembly reference in the project file, what assembly on disk is that reference going to actually refer to at compile time?
Given a XAML file, what is the code that is going to be generated by the XAML compiler at compile time going to look like?
Given a glob file pattern (*.cs), what files are actually going to be included at compile time?
So the files, being generated on the fly, are not needed in your Git repo, and can safely be excluded. Moreover, from what I can tell, these files are specifically made and used by Visual Studio 2017.
I'm debugging a .NET 4.0 application in Visual Studio 2015. My application builds and runs fine, but when I try to edit and continue while running under the debugger, regardless of what changes I make or where I make them in my main project, I get a dialog that says:
Edits were made which cannot be compiled. Execution cannot continue
until the compiler errors are fixed.
As an example of the sort of change I'm talking about, I've tried adding this line in various methods:
Console.WriteLine("foo");
When I look in Visual Studio's Error List pane, I see only one error, CS7038, with the description "Failed to emit module '<my app name>'." No filename, line number, or character is given. There are no squiggly red underlines in my code. If I stop the running application, build with the changes, and run again, everything builds and runs just fine. So there seems to be some discrepancy between what the build-time compiler and the edit-and-continue compiler consider acceptable.
Does anyone know of a way to get more information about why the compile fails in Edit and Continue mode? I read something about attaching to and debugging the VBCSCompiler process, so I tried that, but even with all exception types set to break when thrown, the attached VS never broke.
I'm not sharing any code because this isn't a question about my code but rather about strategies for finding out what the Edit and Continue compiler thinks is wrong, and for all I know the source of the compiler error could be anywhere in my entire project.
Edit:
As mentioned in the comments, I was able to attach a debugger to Visual Studio and break when an exception was thrown upon clicking "Continue" after editing code. The exception was a System.NotSupportedException with the following message: "Changing the version of an assembly reference is not allowed during debugging". It listed the name of the assembly in question, which was a small VB.Net project used by my application, which is mostly in C#. I'm trying to build up an MCVE to submit to Microsoft, but currently I'm unable to reproduce the problem in a smaller solution with just one VB and one C# project.
Edit 2:
I've found a workaround and self-answered the question in case anyone else ever encounters this weird problem, but I'm reserving the "Answered" check mark for anyone who can explain what's going on (why the compiler thinks the version number of the referenced project has changed during the edit).
I found a workaround for the problem, but I don't fully understand what was going on. In the VB.NET project whose assembly version the Edit and Continue compiler said was changing, there was a file called "AssemblyInfo.vb". That file contained the following line:
<Assembly: AssemblyVersion("3.0.*")>
The assembly version can also be set in the Project Properties, via the "Assembly Information" button in the Application tab:
When I removed the AssemblyVersion line from AssemblyInfo.vb, my Edit and Continue problem went away. At first I thought this was because the fields in the Assembly Information window were saved to a different file from AssemblyInfo.vb and there was some conflict between the two, but now I see that the Assembly Information window is just a handy way to edit AssemblyInfo.vb: if I delete the line in AssemblyInfo.vb, it gets cleared in the Assembly Information window.
After some more experimentation, it appears that the asterisk in the version number is the culprit. If I fully specify the assembly version, my Edit and Continue problem goes away. And the referenced project has to be a VB.NET project. I tried the same setup with a C# project, and I could Edit and Continue just fine.
This appears to be very much an edge case, and I'll submit a bug report to Microsoft, but in the meantime I'd love to know what is actually going on with the compiler--why it's getting two different assembly versions of an assembly that really shouldn't need to be recompiled during the debugging.... If you have a good explanation for what's happening, please add it as an answer.
Edit: here's the bug report I filed.
This happened with me in a .net 4.8 app with Visual Studio 2019.
I have a mix vb and cs projects, here the problem appears when a vbproj references a csproj that uses the wildcast operator '*' to specify the version of the assembly.
As commented above by #Wai-Ha-Hee, the wildcast uses the current time, I belive when VS rebuild the application to apply the edits you have made, the version of the assembly changes causing the error.
In assemblyInfo file (of the project present in error) Change:
[assembly: AssemblyVersion("1.0.*")]
To:
[assembly: AssemblyVersion("1.0.0.0")]
It Solved for me.
An important thing to say is the use of wildcast '*' make the assembly non-deterministic, it means each build produces a different assembly. This has been considered bad practice because build the source code in the same conditions generates different assemblies.
In Visual Studio 2019:
New csproj/vbproj with non-sdk style projects file are generated with:
<Deterministic>true</Deterministic>
And new csproj/vbproj with Sdk style projects file omits this line but assumes deterministic as default too.
I recommend considerate other ways to version the assembly.
More about Deterministic:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/
One of my C# projects in a mixed solution was .NET Framework 2.0 (while others - both C# and VB.NET - were .NET Framework 4). After I changed it to .NET Framework 4 it began to work.
I have a class library lets call it UtilityLibrary.
I have a console application. So I right clicked on my solution and added an existing project (UtilityLibrary). I noticed that I can change the code of UtilityLibrary from within my console application.
The issue is if I had added UtilityLibrary to another application and the code had been changed it could causes issues. I was trying to avoid adding a dll reference so thought I would add a reference to my project however I am worried about the code being edited.
Have I added the reference to my project incorrectly?
If you where to check the Debug or Release folder if your console application you should see a UtlityLibrary.dll file, which would still mean that you are, in the end, adding a DLL reference (visual studio will do it for you).
Since you do not want to allow external entities to change your application, simply add a DLL reference instead.
Just to clarify, you can only change the source of one DLL from another application becuase visual studio can find the source files and makes them available to you.
No. You have done nothing wrong. And you can't just change the code of the compiled assembly. You are utilizing a feature from Visual Studio. Since you've build on this machine, and the PDB's are included, it can tell the assembly originated from that source code on your machine. So it allows you to edit it.
These edits don't come in the compiled assembly immediately, you have to compile it again in order to be in the assembly. (Note that you can extract the source code from any .NET assembly by using Refactor for example)
I am working on an assembly that handles various color transformations. When I load the assembly into a new project to test, if there happens to be an bug in the assembly, Visual Studio opens the offending code from the DLL. I can step through all of the code in the assembly.
I definitely don't want the code to be so easily visible/available. I would like the code to be somewhat "locked" in the assembly.
How can I set the DLL to simply throw some sort of error instead of opening?
Edit
I'm not interested in the code being "safe" and I have no need to obfuscate. This library is being used internally and the code itself is perfectly accessible to tohers. What I don't want is for someone using the library to find themselves suddenly debugging the assembly. If there is a problem, I prefer to have an error thrown instead of the assembly code opening in Visual Studio.
This is happening because you have VS installed on the machine, and because you are deploying the PDB files - you will not get this dialogue box if VS is not installed.
Additionally:
Do not deploy code that has been built in the Debug configuration. These contain additional information that helps with debugging.
Make sure you do not deploy the PDB files with the executables. Same as above, and they are not needed for running the code.
Both these will help, but any assembly would be easily decompiled with reflector, so you may also want to investigate obfuscators to stop other programmers from easily seeing your code.
There is a list of C# obfuscators here : http://www.csharp411.com/net-obfuscators/
What you need is to obfuscate your binaries.
Basically if you want your code to be safe and you dont want your classes are exposed to others, you should definitely need to Obfuscate your code.
To obfuscate your code you can use DotFuscator, it is included with Visual Studio installation.
check my article on it.
http://www.codeproject.com/KB/dotnet/code_security.aspx