I set <Deterministic> to true in my .csproj file as specified in the docs to create deterministic outputs.
I need any team member on any machine to be able to create the exactly same DLL when builds our project.
However, when I build, and compare my DLL files to my teammate's DLL files, I see that some files are different.
How can I debug this? How can I find out where the problem might be?
We have the same versions of .NET SDK and Visual Studio. We have the same versions of Windows. Almost everything is the same.
I want to know how can I troubleshoot this problem. Thank you.
Related
I'm making a load of code bits that will eventually be used in another C# program long term, but I may want to use it in various other apps, and I need to use it easily now as it gradually develops. So I've written a few C#.net DLLs in Visual Studio Express 2017. Two of which reference a 3rd-party DLL (one of which was installed by other software, one of which I just pointed at in Visual Studio), and one of my DLLs references my other 2 DLLs. I've ticked the boxes to COM register my ones and I'm now happily using them from Excel/VBA.
But how do I install it on another Win10 machine in simple steps though, so I can use the same spreadsheets and automation on those computers? (preferably with some explanation of what the steps are actually doing?) I haven't had any luck with the other options I've googled, maybe they're not "idiot proof" enough for me, or my DLLs have dependencies on other DLLs, or I'm getting them from the wrong place.
I assume these are 64-bit DLLs (they're complied for 'Any CPU') so I
want to copy them into the 64-bit place (syswow64)? Or should they go
in system32 as well?
I guess I get them from my 'release', not 'debug' folders?
I also have .pdb and .tlb as well as .dll. Do I need these? Maybe they're the missing piece of the jigsaw?
What's the difference between regsvr and regasm and what should I be using? (Or both).
Also is there a simple way to make a DLL copying and COM registering installer app? And if yes, does that still apply if it's VS Express
2017?
Thanks for the help!
When I go into my bin debug folder and move the exe out of it, which depends on a library I have installed in Visual Studio, it will crash because it can no longer find the library it needs.
I was wondering how you can build a library into the app so it will be able to run anywhere instead of just in the bin/debug folder.
Thanks!
Basically you ask for static linking of dll files, which is not the intended approach; the question can be seen as a duplicate of this question.
you have 3 options.
1) create an installer. this is a decent way: http://wixtoolset.org/
(we use http://www.advancedinstaller.com/) it works well but expensive.
2)bad idea embedd the dlls inside the exe
3) bad idea just copy all the referenced files
Here is a short video of my error.
It is obvious that I have something wrong between 32-bit and 64-bit. However I cant find anything that holds my hand enough to walk through the solution in Visual Studio 2012.
Can anyone give me a more detailed explanation of what and how to change in my settings?
The "startup project" (the one that builds the .exe file) determines whether the process will run 32 or 64 bits. Any library that is referenced must support the same "bitness".
If you use libraries that requires a specific CPU type, you should change the "Target CPU" property in the "Build" tab of the project properties of the project that creates the main executable to that CPU type.
Any managed library that you use, that does not depend on cpu-specific libraries can be compiled as "Any CPU".
I don't know the library you're using, but this link makes me think it requires a 32 bit build.
EDIT: I just realized I only know earlier versions of Visual Studio, so the option may be located elsewhere in 2012.
I've dealt with a similar issue just a few days ago. It wasn't as straightforward as one would expect (given the error), I had to use dependency walker in order to check if all needed dependencies of my dlls were in the correct format, turned out my dll was importing an incorrect dependency.
Dependency Walker
I'm working with the Saxon library in .net. I recently submitted a report that there may be a bug, but I'd like to work with the source code myself. I downloaded the code from http://sourceforge.net/projects/saxon/files/Saxon-HE/9.5/saxon9-5-1-1source.zip/download.
The download is a zip archive with three folders: api, cmd, and net. The first two contain C# code files and the third contains Java codes files. I want to compile this code to .net, and I understand that it uses a library called IKVM to bridge the gap between .net and Java.
However, coming from a .net background, I don't even see a project file that I can open with Visual Studio. How am I supposed to compile this source?
In the saxon-resources download at
http://sourceforge.net/projects/saxon/files/Saxon-HE/9.5/saxon-resources9-5.zip/download
you will find a "build" directory containing Ant build scripts. You need to run build.xml with target "product-hen". Since the build scripts are designed to build the entire set of Saxon products, you may need to edit out parts that aren't needed. You will also have to make sure the dependencies are satisfied, in particular of course IKVMC itself.
Building Saxon, especially on .NET, is not for the faint-hearted. It can't be done within Visual Studio because VS does not support Java or IKVMC.
We use Make to compile our product, which includes, C, C++, Java and a bunch of other bits and pieces. As much as possible we have all tools required to compile the whole thing checked into source control, to eliminate local dependencies and to ensure consistency across dev machines.
Recently we've added some components written in C# using Visual Studio and would like to take a similar approach with Visual Studio solutions. Shelling out to devenv isn't a good option. Calling csc.exe directly (as I've done before using Nant) would require keeping track of file dependencies in the build script, which I'd rather just let the Visual Studio solution do.
MSBuild seems like a good bet, though its default location in %windir%\Microsoft.NET\Framework\[version]\ makes me worried about variability between machines, both with the [version] in the path and the fact that you'll see both "Framework" and "Framework64" directories. I wouldn't mind having a requirement that all developers have whatever .NET framework version installed, but I do worry that your v3.5 might not be the same as mine.
Does anyone have a solution to this that they like? Tried anything that you really didn't like?
MSBuild is the lowest-friction option for sure. Different fx versions aren't that big a deal at build-time- if you're using something important from a fx version higher than what's installed, it won't build. The last place I was at, we built a huge multi-environment build system with NAnt as the base, and it hooked out to MSBuild with NAnt's MSBuild tasks. MSBuild is fine on its own if you're just doing MS stuff, but we had a bunch of things that MSBuild didn't natively support, hence the NAnt wrapper.
I agree with everyone else. To make it easy, just make vsvars.bat (the batch file that is the Visual Studio Command prompt) part of your build script, and then MSBuild will just work.
We use Nant to drive msbuild. If you're worried about different versions of the framework, particularly service packs, use FxCop to check that you're not letting unexpected dependencies creep in. Details are in this answer.
MSBuild is the right tool for this job. Just match your framework version to the version of the framework bundled with the Visual Studio you're using.
32-bit versus 64-bit shouldn't matter, I don't think -- I'm pretty sure both the 32-bit and 64-bit editions of Csc.exe can cross-compile to the other platform. The MSBuild project file (*.*proj XML file) should contain everything MSBuild needs to build your application.