I'm working on msbuild to get version info from assembly file. But i got a problem that the value $(MaxAssemblyVersion) is always empty. The only difference here is that i got a .Net solution including several projects. So i have a GlobalAssemblyInfo.cs at the root folder and Assemblyinfo.cs inside every included project. Anyone has any suggestion for my situation? Is there any way to work with GlobalAssemblyinfo.cs?
Look forward to your reply!
Every comment will be very helpful and appropriated.
Many thanks,
Depending on what point during the build you need the assembly version, you could extract it from your outputs using the GetAssemblyIdentity Task.
Related
Latest:
This is definitely a bug in msbuild. Other than that there cannot be any other explanation. This could only be happening on Linux or possibly on a wider range.
So i decided to just build one single project with absolutely no dependencies on others in the solution.
Looking at the captured diagnostics, I see these lines which are very promising:
Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
Input files: Annotations.cs;Auth.cs;AuthorizationConfig.cs;Backend.cs;Billing.cs;Code.cs;...
Output files: .obj/TheAgent.dll;.obj/TheAgent.pdb
Set Property: NoWarn=;1701;1702
15:23:27.396 1>Done building target "CoreCompile" in project "TheAgent.csproj".: (TargetId:40)
It looks like my dll and my pdb weren't built which is what I expected.
However, something must be happening before or after causing the timestamp to change (be that of this build time and not the last).
The timestamp of the dll is updated both in the intermediate object folder (.obj/) and also in the output folder.
Is there a known way of stopping msbuild right after its CoreCompile task?
Update:
I decided to search for is newer this time and found instances of these. I don't know how they have got to the solution/project files though:
Input file ".obj/Common.csproj.CoreCompileInputs.cache" is newer than output file ".obj/Common.pdb".
Further to the above, I came across this:
https://github.com/dotnet/project-system/issues/4736
Thinking that this was the issue, I upgraded to dotnet sdk version 2.2.402.
The end result is still the same :(
Original:
I need some pointers on how to troubleshoot this issue. I am using /t:build to build a solution file.
The resulting executable keeps getting refreshed each time.
First i thought the package restore was causing this. I have removed that step however it didn't make a difference.
Then I looked at this:
https://oz-code.com/blog/visual-studio-keeps-rebuilding-projects-no-good-reason/
I'm basically looking for some text in the diagnostics output which tells me if a target or a file is out of date and needs to be rebuilt. The above link talks about "project 'B' is not up to date". I don't have a not up to date in my msbuild output.
I already had two resources with CopyAlways which I changed to CopyIfNewer.
The above article also talks about circular dependencies. I am checking everything manually. And yes the references to dependent project are actually references to the project outputs (dll's /exe's). So Finding a circular dependency by just checking for that pattern seems a little odd.
There was one more problems in the dotnet platform and/or msbuild causing this to fail.
One of those was this https://github.com/dotnet/project-system/issues/4736
Installing SDK 3.0.100-preview7-012821 or better solved the problem
This should be an easy one, but it's driving me mad. I'm new to implementing plugins, and one that I'm looking at has the following dependency:
<depends>com.intellij.modules.lang</depends>
I cloned the intellij-community project and was expecting to see this defined as an extensionPoint in one of the many plugin.xml files in the project, but either I can't search correctly or it is somewhere else.
Anybody knows where I can find this definition?
Thanks,
a
I'm still no expert in plugin development, but I think I figured out parts of my problem.
First, I was wrong about com.intellij.modules.lang having to be defined as an extension point. Name of extensions need to have corresponding extension points, not dependencies.
Then com.intellij.modules.lang is defined in a
<module>
tag in a few xml files in the intellij source code, which is part of the SDK used by this project. One such file is platform/platform-resources/src/META-INF/PlatformLangPlugin.xml. Now I need to familiarize myself with the concept of modules, but the original question is not moot.
Thanks to anyone who spent a few seconds thinking about this problem.
I once had TeamCity + WiX + MSBuild Community Tasks working. Now that I've upgraded to WiX 3.5, I can't remember how I had configured it. :) As I was poking through TeamCity, I came across the "AssemblyInfo Patcher". I thought, "Great! This will make my life much easier!". I used %build.vcs.number.1% for the format and built my installer.
While the patcher did pull in the vcs number, it used it for the major number in the version. So instead of 1.0.0.xxxx, it made the version xxxx.0.0.0.
I looked through JetBrain's documentation site and came up with nothing related to changing this to a more appropriate setting. I also looked for regex support, but didn't find anything.
Can anyone suggest a good solution, or should I just go back to trying to configure my original set of tools?
The assembly info patcher only patches the complete version string at once. But the system variable build.number can be generated from the "general" page of the build configuration, like this:
When you specify %build.number% as your AssemblyInfo version, it will pick up the combined number from your General settings page.
Try including the full intended version number as part of your format:
1.0.0.%build.vcs.number.1%
Hmmm haven't seen AssemblyInfo Patcher but you can do it manually using MsBuild and Regex:
http://jonalb.com/post/2010/10/04/Automatic-Versioning-using-TeamCity-an-MSBuild.aspx
I'm trying to write a IL Weaver with Mono.Cecil, and for it to remain debugable in VS2010, I need the PdbReaderProvider class, or some similar implementation of ISymbolProvider. I've downloaded the latest Mono dlls from http://mono.ximian.com/daily/, but in the zip there is no Mono.Cecil.Pdb.dll. I've downloaded the source code from https://github.com/jbevain/cecil/tree/master/Mono.Cecil but I can't seem to be able to get that particular project compile under .net 4.
Could somebody help me out and point to a compiled working .net dll of Mono.Cecil.Pdb, preferably with a working PdbReaderProvider inside?
Indeed, you need to get the source from Cecil's github repository. Then you just have to open Mono.Cecil.sln inside VS 2010, select the solution configuration net_4_0_Debug (or net_4_0_Release) and build the solution. The solution is self contained so you don't need anything else.
You'll get both Mono.Cecil.dll and Mono.Cecil.Pdb.dll inside bin/net_4_0_Debug (or bin/net_4_0_Release).
Alternatively, get the NuGet package which includes all Cecil assemblies. If you're on the MS stack, of course.
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.