How do I pass assembly version from build step to next step - c#

I have a simple windows application in my Azure DevOps repo. I'm trying to set a build for it so I can practice using the Azure Pipelines.
How would I pass the assembly version of the c# windows application which resides in the AssemblyInfo.cs file under the project properties to use in a next step of the pipeline?

First you need get assembly version. You can use powershell script to read that value from file. This post may help you with that
You need set variable to keep you assembly version. It also can be done in powershell script. You can read about this here
Write-Host "##vso[task.setvariable variable=AssemblyVersion;]$assemblyVersionFromFile"

Related

Accessing Published Version Number In .Net6 Windows Forms App [duplicate]

I have a windows forms application that is deployed to two different locations.
Intranet - ClickOnce
Internet - Installed on a citrix farm through Windows installer
I display ClickOnce version number for click-once deployed versionApplicationDeployment.IsNetworkDeployed.
if (ApplicationDeployment.IsNetworkDeployed)
return ApplicationDeployment.CurrentDeployment.CurrentVersion;
But for the non-click application, I am not sure how to retrieve clickonce version unless I hardcode the version number in assembly info.
Is there an automatic way of retrieve ClickOnce version number for non-clickonce deployed version?
Add an assembly reference to System.Deployment to your project.
Import the namespace in your class file:
VB.NET:
Imports System.Deployment.Application
C#:
using System.Deployment.Application;
Retrieve the ClickOnce version from the CurrentVersion property.
You can obtain the current version from the ApplicationDeployment.CurrentDeployment.CurrentVersion property. This returns a System.Version object.
Note (from MSDN):
CurrentVersion will differ from UpdatedVersion if a new update has
been installed but you have not yet called Restart. If the deployment
manifest is configured to perform automatic updates, you can compare
these two values to determine if you should restart the application.
NOTE: The CurrentDeployment static property is only valid when the application has been deployed with ClickOnce. Therefore before you access this property, you should check the ApplicationDeployment.IsNetworkDeployed property first. It will always return a false in the debug environment.
VB.NET:
Dim myVersion as Version
If ApplicationDeployment.IsNetworkDeployed Then
myVersion = ApplicationDeployment.CurrentDeployment.CurrentVersion
End If
C#:
Version myVersion;
if (ApplicationDeployment.IsNetworkDeployed)
myVersion = ApplicationDeployment.CurrentDeployment.CurrentVersion;
Use the Version object:
From here on you can use the version information in a label, say on an "About" form, in this way:
VB.NET:
versionLabel.Text = String.Concat("ClickOnce published Version: v", myVersion)
C#:
versionLabel.Text = string.Concat("ClickOnce published Version: v", myVersion);
(Version objects are formatted as a four-part number (major.minor.build.revision).)
No I do not believe that there is a way. I believe the ClickOnce information comes from the manifest which will only be available in a ClickOnce deployment. I think that hard coding the version number is your best option.
I would simply make the assembly version of the main assembly the same as the CLickOnce version every time you put out a new version. Then when it runs as a non-clickonce application, just use Reflection to pick up the assembly version.
Try thread verification:
if (ApplicationDeployment.IsNetworkDeployed)
{
if (ApplicationDeployment.CurrentDeployment.CurrentVersion != ApplicationDeployment.CurrentDeployment.UpdatedVersion)
{
Application.ExitThread();
Application.Restart();
}
}
not that it matters three years later, but I ended up just parsing the manifest file with xml reader.
To expand on RobinDotNet's solution:
Protip: You can automatically run a program or script to do this for you from inside the .csproj file MSBuild configuration every time you build. I did this for one Web application that I am currently maintaining, executing a Cygwin bash shell script to do some version control h4x to calculate a version number from Git history, then pre-process the assembly information source file compiled into the build output.
A similar thing could be done to parse the ClickOnce version number out of the project file i.e., Project.PropertyGroup.ApplicationRevision and Project.PropertyGroup.ApplicationVersion (albeit I don't know what the version string means, but you can just guess until it breaks and fix it then) and insert that version information into the assembly information.
I don't know when the ClickOnce version is bumped, but probably after the build process so you may need to tinker with this solution to get the new number compiled in. I guess there's always /*h4x*/ +1.
I used Cygwin because *nix scripting is so much better than Windows and interpreted code saves you the trouble of building your pre-build program before building, but you could write the program using whatever technology you wanted (including C#/.NET). The command line for the pre-processor goes inside the PreBuildEvent:
<PropertyGroup>
<PreBuildEvent>
$(CYGWIN_ROOT)bin\bash.exe --login -c refresh-version
</PreBuildEvent>
</PropertyGroup>
As you'd imagine, this happens before the build stage so you can effectively pre-process your source code just before compiling it. I didn't want to be automatically editing the Properties\AssemblyInfo.cs file so to play it safe what I did was create a Properties\VersionInfo.base.cs file that contained a text template of a class with version information and was marked as BuildAction=None in the project settings so that it wasn't compiled with the project:
using System.Reflection;
using EngiCan.Common.Properties;
[assembly: AssemblyVersion("0.$REVNUM_DIV(100)$.$REVNUM_MOD(100)$.$DIRTY$")]
[assembly: AssemblyRevisionIdentifier("$REVID$")]
(A very dirty, poor-man's placeholder syntax resembling Windows' environment variables with some additional h4x thrown in was used for simplicity's/complexity's sake)
AssemblyRevisionIdentifierAttribute was a custom attribute that I created to hold the Git SHA1 since it is much more meaningful to developers than a.b.c.d.
My refresh-version program would then copy that file to Properties\VersionInfo.cs, and then do the substitution of the version information that it already calculated/parsed (I used sed(1) for the substitution, which was another benefit to using Cygwin). Properties\VersionInfo.cs was compiled into the program. That file can start out empty and you should ignore it by your version control system because it is automatically changing and the information to generate it is already stored elsewhere.
Hard code, or... Keep track on your versions (File, Assembly, Deploy) in a database. Make a call to the database with your Assembly and get the Deploy version.
This assumes that you are incrementing your versions in a logical way such that each version type has a relationship. It's a lot of work for such a minor problem. I'd personally go with Jared's solution; although I hate hard coding anything.
Using a build component, you could read the click-once version from the project file and write it automatically to the assembly info so both of them are in sync.
Solution for .NET (Core) 7 and higher
On .net Core, you can read the version number from the environment variable ClickOnce_CurrentVersion.
string versionString = Environment.GetEnvironmentVariable("ClickOnce_CurrentVersion") ?? "0.0.0.0";
Version version= Version.Parse(versionString);
MessageBox.Show(version.ToString());
See documentation

Inspect dependencies for dynamically loaded library in .net core

I'm trying to create plugin which uses some functions from external dll-s.
Because I don't know which plugin will be used I would like to dynamically load:
main asp.net core project which dynamically loads plugins like mailservice.dll using reflection.
mailservice.dll library which exposes CheckMail() method (I use MimeKit as a IMAP helper).
Everything loads fine but when I invoke CheckMail() method I receive System.IO.FileNotFoundException: Could not load file or assembly 'MailKit, Version=1.16.0.0.
So I put all dependencies for MimeKit extracted from release version and still nothing (46 files).
When I install MimeKit package using nuget to my main asp.net project everything runs fine but obviously I don't want keep such dependency.
Is there any tool or technique to inspect which file is missing?
To get assembly probing path from the dotnet core host,you can enable core host tracing.
If you are running from Visual Studio, Go to command prompt and location of your asp.net core main solution
set the environment variable with this command first
set COREHOST_TRACE=1
After that just run using dotnet run and you will get full details
To redirect the output to the text file,use redrection
dotnet run 2> log.txt
note: You need the '2>' redirection as dotnet host writes to the STDERR stream and not STDOUT.Your regular logging will be STDOUT .Hope this helps

How do I mimic the build and deploy functionality in the AWS Toolkit for Visual Studio via a script?

I have a .NET solution with several different projects. Each of them I have now set up via the AWS Toolkit so I can just right click and hit "Redeploy to AWS..." but what I would like to do create a script (PowerShell maybe?) that builds and deploys all of my projects automatically.
I know there is a CLI version of the AWS Toolkit called awsdeploy.exe but it doesn't seem like that will perform the compilation and archiving of a project like the AWS Toolkit plugin does.
How do I mimic this behavior?
So I'm currently tackling this question at work, with partial success. What I have found is that you can do the packaging with msbuild, and then deploy with awsdeploy.
For example, if I have a visual studio solution call bas, with two projects, foo and bar, and I want to deploy bar, then I first package bar with msbuild.
msbuild bar/bar.csproj /t:Package /p:PackageLocation=barPackage.zip
This should create a package call barPackage.zip under the bar directory. If you don't find it, look at the msbuild output as it should let you know where it was created.
Now that we have the package, we can deploy. Awsdeploy needs a configuration file. It's just a file that contains key value pairs of the form "key = value". There is an example file in a directory called Samples\, in the same directory where the awsdeploy.exe is located.
If you are using visual studio there is an option for creating the config file while deploying to aws.
More info: http://docs.aws.amazon.com/AWSToolkitVS/latest/UserGuide/tkv-deployment-tool.html#deployment-tool-configuration-file-format
Let's assume we have a configuration file called deployConfig.txt then we can call awsdeploy like so
awsdeploy /r deployConfig.txt
Note that the /r is for redeploy. This assumes that you already have an environment running.
If you don't want to put credential inside the file, you can also do.
awsdeploy /r /DAWSAccessKey=stuff /DAWSSecretKey=stuff deployCon
In general anything we don't want on the file we can specify on the command like by adding /Dsomething=stuff. As you can see above to specify AWSSecretKey we do /DAWSSecretKey=stuff.
The visual studio generated file does not list the location of the package so what I've been doing is
awsdeploy /r /DAWSAccessKey=stuff /DAWSSecretKey=stuff /DDeploymentPackage=bar/bar.zip deployConfig.txt
This almost works for me. But sadly it doesn't quite do the trick. It deploys the package, and I can see the environment trying to load it but fails at some point. I don't know why it's failing to load it. It loads it fine when I deploy it from visual studio.
This is how we're handling it. All of this runs on our CI server:
Step 1 - build web deploy package with msbuild:
msbuild website.csproj /t:WebPublish /p:WebPublishMethod=Package
/p:DesktopBuildPackageLocation=website.zip /p:Configuration=Release
/p:DeployIisAppPath="Default Web Site"
Step 2 - deploy with awsdeploy:
awsdeploy.exe /DAWSAccessKey=**** /DAWSSecretKey=**** /r config.txt
config.txt:
DeploymentPackage = .\website.zip
AWSProfileName = ******
Region = us-east-1
Template = ElasticBeanstalk
UploadBucket = ***********
Application.Name = ***********
Environment.Name = ***********

stamping the username on c# assembly - who build this dll

So, here is what I am trying to do.
I am trying to stamp name of the user who compiled the particular project. As link assembly version is there any way by using that I can store the original user name on dll.
I tried creating custom attribute and using it in AssemblyInfo.cs, but it gives me the username of person who is running the dll and not who build it.
Any help will be appreciated.
For modifying the Assembly info I use a pre-build event that executes a batch file for the modification.
You could write a custom MSBuild action that updates an assembly attribute in a known file prior to compilation. This has the downside of having to install the custom build step on all dev machines and any build machines.
So here is I found I am trying trick.
I have created new custom attribute AssemblyCompiler. And by changing and using powershell script shown here . Seems it works.
Another C# solution
Create new custom attribute
write c# program to update/add username
call that c# code on prebuild event as follows
call ....\Resources\OverwriteAssemblyInfo.exe [ I placed my the executable file in resources]

including Closure Compiler into an asp.net app

I'm using Closure Compiler in my application. For the moment, I use XML to send my javascript to the CC's web service and compile the code. What I want to do is include CC into the project itself so that the compilation doesn't rely on the web service but is done entirely on the server. How do you include the .jar files that are downloaded in the CC download package and make it work in .net?
Thanks.
The simplest solution is just to put the CC folder on that server and then add it's path to your $PATH. Another option is to add it as a resource in the project and then set Copy to Output Dir to Always or If Newer and use a relative path to access it. I believe the second option is better because it removes the outside dependency.
Once you have the file there you can start a command line process with the commands like they have in the docs java -jar compiler.jar --js hello.js --js_output_file hello-compiled.js and it will do what you want. There is of course also a Java dependency. For some basic info on starting process' in C# check out http://msdn.microsoft.com/en-us/library/system.diagnostics.process(v=vs.110).aspx

Categories

Resources