Develop Reference

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

SQLite.Interop unable to delete file on clean of solution

I'm using the Nuget package System.Data.SQLite in an MVC web application. There seems to be lock issue when I try to clean the solution and rebuild. The error message I get is:
Unable to delete file "bin\x64\SQLite.Interop.dll". Access to the path '\bin\x64\SQLite.Interop.dll' is denied.
I'm thinking that the database is either still open or that the .dll is still in use, but I can't find any documentation or any reference to the same problem. This question seems like a similar issue but doesn't provide a resolution to my problem.
Here is a code snippet that I'm using to write to the SQLite database:
var conn = new SQLiteConnection("Data Source=" + connectionString);
conn.Open();
var debugEntriesTableQuery = "CREATE TABLE ...";
var cmd = conn.CreateCommand();
cmd.CommandText = debugEntriesTableQuery;
cmd.ExecuteNonQuery();
conn.Close();
Is there another step needed to properly close the connection to the database and inform the dll and the connection has closed?
I am using this code inside a data solution that I have added to a nuget package and am using in another solution. I am only having this problem when building/cleaning the solution that is using my nuget package.

Killing the IIS Express process solves this error for me as pointed out by the link Eric points to. I am using Visual Studio 2015 community. I exit the IIS Express process from the taskbar.

xul.dll not found error when using GeckoFX browser control

I am using "GeckoFx-29.0-0.6" for having a firefox web browser control in Windows Form application.
When I run my Windows form application which have GeckoFX browser control everyting is working fine.
I use the following code in my application,
Gecko.Xpcom.Initialize("xulrunner/");
and I use xcopy to load the bin folder with xulrunner folder. So in this scenario the xul runner is loaded from the same loaction where the application .exe is found.
When I make wix setup of my application, I am doing the same process, I have xulrunner folder in the same location as application .exe. But the application is not able to invoke the windows form. Its showing the message "unable to load DLL 'xul'".
I resolved this issue by changing my setup such that the xulrunner folder is copied to the c:/windows/system32 folder location. When I do so, the application works successfully in some machines but do not work in someother.
Is there any way to resolve this? such that I don't need to put the xulrunner in the system32 folder ?

You can try giving the full path to the xulrunner directory. Do something like:
var programDirectory = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location);
Gecko.XpCom.Initialize(Path.Combine(programDirectory, "xulrunner");
That will work when the app is installed, and if you've placed xulrunner in your output directory. If you don't want to bother copying it in there, then you will want to make the above code a bit smarter so that when you're just running from Visual Studio, it can locate xulrunner where you have placed it.
Our class for smartly finding files under a number of conditions, FileLocator, is open source, you can grab it and use it.

I have wasted lot of time trying to fix the issue and found that the error was due to mismatch of geckofix and xulruneer version. they both should be same. checkout this link to understand more https://bitbucket.org/geckofx/geckofx/wiki/Version_lists

Heads up, I know this post is old, but I discovered something. If you use Visual Studio (2019 is the version I have, at the time of this post), and you added the Geckofx45.64 via NuGet, there is also a Geckofx45.64.Windows package. When you read the description of this package from Visual Studio NuGet Manager, it says:
This should only be used for building Geckofx... Do NOT use this
package if you just want to include Geckofx in your application.
Well, I downloaded it anyway, and checked the contents of this package and noticed that it had all the files that Geckofx.45 was complaining about missing during run-time (init). I, therefore, added the package, and Geckofx now works exactly the way it instructs.
library that allows embedding gecko in C# applications.
Example Usage:
[STAThread]
static void Main(string[] args)
{
Xpcom.Initialize("Firefox64");
var geckoWebBrowser = new GeckoWebBrowser {Dock = DockStyle.Fill};
Form f = new Form();
f.Controls.Add(geckoWebBrowser);
geckoWebBrowser.Navigate("www.google.com");
Application.Run(f);
}
Hope this helps. This one had me going in circles for a while.

You'll get that error when you forget to run the line Xpcom.Initialize("Firefox64"); before using GeckoWebBrowser.

This also works
Gecko.Xpcom.Initialize(Environment.CurrentDirectory + "\\xulrunner");

EmguCV 64-bit build runtime error

I am running into issues building an existing 32-bit EmguCV (Version 2.3) into 64-bit using .net 4.0 and VS2010 on a W7/x64 OS. I have purchased a commercial license, if that matters and downloaded from the links provided in the receipt.
The error is
System.TypeInitializationException was unhandled
Message=The type initializer for 'Emgu.CV.CvInvoke' threw an exception.
Source=Emgu.CV
TypeName=Emgu.CV.CvInvoke
I followed the instructions provided in this article. In fact I used the samples projects in the article and they build fine with V2.2, but when I replace with V2.3 binaries (both emgu and opencv), run into the error.
Has anyone successfully built an Emgu (Version 2.3.x) x64 project? Please provide some guidance.

The cause of this error (should anyone else run into the same problem) is that the program cannot access opencv_imgproc231.dll or opencv_core231.dll even though they are present in the output "bin" directory.
There are two solutions:
Add them to the project and set their properties to copy always as they are EMGU's two key files.
If step 1 doesn't work, replace the current key files in the bin folder with new copies.
If both methods fail then there may be a problem with the build, so download a new copy of EMGU from Sourceforge and try again. The error will later be incorporated within an technical article in order to provide a clearer explanation of how to solve it.
Cheers,
Chris

No need to add them to the project; VS will not let you. Simply open FaceRecognizer.cs
at public static partial class CvInvoke and change:
[DllImport(CvInvoke.EXTERN_LIBRARY, CallingConvention = CvInvoke.CvCallingConvention)]
to:
[DllImport(Emgu.CV.CvInvoke.EXTERN_LIBRARY, CallingConvention = Emgu.CV.CvInvoke.CvCallingConvention)]
Ensure you change all of them.

First test this way: open a sample project from emgu cv installaiton directory and run it. for example, open hello world example and try to run it. if sample projects run with out problem then the installation is correct.
For emgu cv sample projects, value of Output Path option in Build settings of the project is set to '..\..\
bin'. To fix your project problem, open the project in visual studio and set value of Output Path option to 'C:\Emgu\emgucv 2.9\bin'. Try to run the project. It must run with success.
Now, set back the value of Output Path option to bin\Debug\. Then, add all DLL files in the 'C:\Emgu\emgucv 2.9\bin' folder to your project using ADD -> Existing Item menu. similarly, add all DLL files in the 'C:\Emgu\emgucv 2.9\bin\x64' folder to your project using ADD -> Existing Item menu. Now, go to properties window and set Copy to Output Directory option of all dll files to Copy Always. Finally, in the Configuration Manager window, create a new configuration for x64 platform.
Good Luck

sqlite3.dll and system.data.sqlite.dll

Hello people I've been struggling to use sqlite in my C#2.0 application and I have finally decided to get rid of assumptions and ask really basic questions.
When I created a database say iagency with table users, from external tools like firefox plugging and another sqladmin tool I can't query it from sqlicommand inside vs2005 it displays System.Data.SQLite.SQLiteException:Sqlite Error no such table users, please be assured that I've made reference to system.data.sqlite installed with SQLite-1.0.61.0-setup
When I do the opposite like create a database and a table from VS server explorer and VS database gui tools it can't be queried neither but can be seen by other tools, but tables created through query from VS using stringbuilder eg create table bla bla. it can be display in a datagrid but none of the tools can see and display that table.
WHAT DO I NEED EXACTLY TO MAKE SQLITE WORK IN MY APPLICATION?
I've tried to add sqlite3.dll of sqlitedll-3_6_14.zip downloaded from sqlite site under section precompiled binaries for windows as reference to my application but it fails with make sure it's accessible an it's a valid assembly or com component.

I downloaded this SQLite-1.0.61.0-setup.exe Ran the installation then I wrote this to access the firefox favorites sqlite db.
using System.Data.SQLite; // Dont forget to add this to your project references
// If the installation worked you should find it under
// the .Net tab of the "Add Reference"-dialog
namespace sqlite_test
{
class Program
{
static void Main(string[] args)
{
var path_to_db = #"C:\places.sqlite"; // copied here to avoid long path
SQLiteConnection sqlite_connection = new SQLiteConnection("Data Source=" + path_to_db + ";Version=3;New=True;Compress=True;");
SQLiteCommand sqlite_command = sqlite_connection.CreateCommand();
sqlite_connection.Open();
sqlite_command.CommandText = "select * from moz_places";
SQLiteDataReader sqlite_datareader = sqlite_command.ExecuteReader();
while (sqlite_datareader.Read())
{
// Prints out the url field from the table:
System.Console.WriteLine(sqlite_datareader["url"]);
}
}
}
}

Try opening up the database in the command line SQLite tool (from SQLite.org), and check the schema.
You can check the schema in this way:
.schema
This will dump out all the SQL necessary to create the tables in the database. Make sure the table is there, with the name you assume it should have.
You do not need the .dll file from SQLite.org, all you need is the assemblies from System.Data.SQLite.

For me - this link helped a lot at start.
Was harder to get subsonic work, to make database accessible through web application -
but that's another story.

You might try adding the location of the assembly and the db to the Path environment variable. The SQLite assembly contains both .Net and native code merged together, so you do not need the C dll. (the mergebin tool they include to do this is pretty interesting)

I also tried adding the location to Path environment variable but without success.
Finally I copied System.Data.SQLite.dll and System.Data.SQLite.lib into the bin folder of the Web application where other assemblies are located, and application worked.