I currently have two projects in my solution, a deployment project which builds the msi and another project which contains my custom actions. I am having trouble referencing my custom actions the same two errros keep appearing:
..\WixSharp Setup\bin\Debug\WixSharpSetup.exe" "/MSBUILD:WixSharp Setup" "/WIXBIN:"" exited with code -532462766. WixSharp Setup ..\WixSharp Setup\packages\WixSharp.1.9.2\build\WixSharp.targets 6
No CA or UI entry points found in module: ..\WixSharp Setup\WixSharp Setup\WixSharpSetup.exe WixSharp Setup ..\WixSharp Setup\WixSharp Setup\EXEC
Deployment project
using System;
using System.Windows.Forms;
using Deploy.CustomAction;
using WixSharp;
using WixSharp.Forms;
namespace WixSharp_Setup
{
class Program
{
static void Main()
{
var project = new ManagedProject("MyProduct",
new Dir(#"%ProgramFiles%\My Company\My Product",
new File("Program.cs")),
new ManagedAction(SearchAPIActions.SearchAPIInstall));
project.GUID = new Guid("6fe30b47-2577-43ad-9095-1861ba25889b");
project.ManagedUI = ManagedUI.Default; //all standard UI dialogs
project.BuildMsi();
}
CustomAction project
public class SearchAPIActions
{
[CustomAction]
public static ActionResult SearchAPIInstall(Session session)
{
session.Log("Begin CustomAction1");
return ActionResult.Success;
}
In case anyone is interested i found the solution to my problem, as the Custom action was compiling to a .dll you need to give a direct reference to it when you declare a managedAction.
new ManagedAction(CustomActions.IISReset, #"Your full Path\Customs.dll"));
Related
When making the file, I am thinking of selecting a console application. But which target framework do I choose? Is this incorrect? Also, I am having trouble figuring out how to make a method in the class Program that is able to be called in the Main method. Can someone give me some advice?
one thing you can do is using interface to keep your code clean; for example :
you create an interface like this:
public interface IQuestionSolving
{
public void Solution();
}
you create some question class :
public class Question1 : IQuestionSolving
{
public void Solution()
{
}
}
and you use it like this :
static void Main(string[] args)
{
IQuestionSolving solve = new Question1();
solve.Solution();
Console.ReadKey();
}
now each time you solve a question you need to change
IQuestionSolving solve = new Question1();
to
IQuestionSolving solve = new Question2(); // 2 3 4 .. etc
you can extract your project as template so you dont have to do this each time .
or you can just use one solution and many classes .
This will get you started with Visual Studio:
Create a new console project - use the latest version of C#, which is probably what VS will "suggest" to you. Currently that's .NET 6 or .NET 7
A modern (net 6 or later) console app lets you start writing code immediately. You could create a method and then call the method right in this little Program.cs file that you start out with. However, I would probably do the following instead:
a) Create a new class for your "problem"
b) In that class create a method that solves the problem.
c) In your Program.cs add a using statement to use the namespace that your new class uses
d) In your program.cs instantiate that class and call its method/test its method
Here is an example:
Program.cs
using LeetCodeProject;
var solver = new Problem001_CalculateSquareRoot();
var solution = solver.calculate_square_root(8);
Console.WriteLine(solution);
Console.WriteLine("Press any key...");
Console.ReadKey();
Problem001_CalculateSquareRoot.cs (solves one leetcode problem)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace LeetCodeProject
{
public class Problem001_CalculateSquareRoot
{
public double calculate_square_root(int number)
{
double root = 1;
int i = 0;
while (true)
{
i = i + 1;
root = (number / root + root) / 2;
if (i == number + 1)
{
break;
}
}
return root;
}
}
}
Now you can just add new classes for each problem, and as you work on them just edit Program.cs to create the class you are currently working with and calls its solution methods.
I can (and would - and actually have, in similar cases) implement an interface for this, but the goal here is not to get into OO design principles, but just to get you started so you can get to work on the leetcode problems...once you have a few done you can start thinking about better organization of the code.
I am creating an ASP.Net MVC application and I have created a new console application just so that I can pass it a few parameters and use the DataContext in the MVC application so that I dont have to continually repeat myself.
This is the code that I am using
using mySite.WebSite.DataModel;
namespace mySite.AvailabilityManager
{
class Program
{
public static List<DateTime>Availability = new List<DateTime>();
static void Main(string[] args)
{
var startingDt = Convert.ToDateTime("04-09-2015 08:00:00");
var endingDt = Convert.ToDateTime("04-09-2015 17:00:00");
CreateAvailabilty(startingDt, endingDt);
AddAvailabilityToDatabase();
}
public static void CreateAvailabilty(DateTime startingDt, DateTime endingDt)
{
var hoursDiff = endingDt.Subtract(startingDt);
for (int i = 0; i < hoursDiff.Hours; i++)
{
Availability.Add(startingDt);
startingDt = startingDt.AddHours(1);
}
}
public static void AddAvailabilityToDatabase()
{
using (var db = new FitnessForAllContext())
{
foreach (var availableDate in Availability.Select(date => new AvailableDate {DateAvailable = date}))
{
db.AvailableDates.Add(availableDate);
db.SaveChanges();
}
}
}
}
When I get to db.AvailableDates.Add(..) I get this error
No connection string named 'MyDBContext' could be found in the application config file.
I was under the impression that because I am using the reference from my MVC application and the connection string is in the ASP.Net MVC config file that I would not have to repeat the connection string in my app.config file for the console application.
So, to summaries,
I have the MVC Project refernece in my console application
This fails because of the lack of a connection string at db.AvailableDates.Add(availableDate);
The mySite.Website assembly is being pulled through into my bin debug folder
If you could offer some insight as to what I need to do without having to continually repeat myself by adding the connection string everywhere I intend on using this, unless I REALLY have to repeat myself
Standard, the connection string needs to be in de config file of the startup project. In this case of the console application. The config of the referenced project is ignored.
You can have a constant or an embedded resource or anything IN your EntityFramework project that contains connection string. But I think, it's not a good practice, every executing project should have it's own configuration.
I have a console application project with NUnit tests in the same project.
I have been trying to apply this solution.
At run-time the solution worked OK. But when I ran the tests by Resharper test runner or NUnit GUI runner, GetExecutingAssembly().Location returned a path like this: d:\Temp\f4ctjcmr.ofr\nojeuppd.fmf\R2Nbs\assembly\dl3\9766f38e\b9496fb3_43cccf01\.
Disabling shadow-copying fixed the problem in both test runners, but new problems appeared (VS is not able to build the project until NUnit Gui is closed). Is there a better solution than disabling shadow-copying?
Update: Environment.GetCommandLineArgs()[0] returned C:\Program Files (x86)\NUnit 2.6.3\bin\ in the tests running in NUnit Gui with shadow-copying enabled.
Alright, this goes into fun territory.
You should be mocking out this dependency.
Example code:
public interface IApplicationRootService {
Uri GetApplicationRoot();
}
public class ApplicationRootService : IApplicationRootService {
public Uri GetApplicationRoot() {
//etc
}
}
Now, apply liberally to your code where you're calling getexecutingassembly and whatnot. Inject the IApplicationRootService as a constructor dependency.
Ex:
public class DoWork {
private IApplicationRootService _applicationRootService;
public DoWork(IApplicationRootService applicationRootService) {
_applicationRootService = applicationRootService;
}
public void DoSomething() {
var appRoot = _applicationRooService.GetApplicationRoot();
//do your stuff
}
}
Now when you're testing, use a mocking service and mock out the return value of application root to the appropriate folder for nunit to go sniffin'.
Ex code, using nunit and moq:
[Test]
public static void test_do_something() {
var applicationRootService = new Mock<IApplicationRootService>();
applicationRootService.Setup(service => service.GetApplicationRoot()).Returns(new Uri("MyRoot", UriKind.Relative);
var myClass = new DoWork(applicationRootService.Object);
//continue testing!
}
The following solution worked for me. Please vote to its author if it helps you.
As explained in the MSDN forums post, How to convert URI path to normal filepath?, I used the following:
// Get normal filepath of this assembly's permanent directory
var path = new Uri(
System.IO.Path.GetDirectoryName(
System.Reflection.Assembly.GetExecutingAssembly().CodeBase)
).LocalPath;
I have been trying with no avail to get this service to install.
I am currently using InnoSetup since the Visual Studio installer just didn't entirely make sense to me, to be honest (It is also 1am. D:)
I took some of the code from this thread: Inno Setup for Windows service?
And everyone there says it worked perfectly for them, but they don't entirely explain what they did or where they put that code. Was it a console application? Where?
So, I stuck it where I thought it might have supposed to go. When you add an installer class to a service, a 'Program.cs' class gets created, so that is where I put it.
Here is my 'Program.cs':
using System;
using System.Collections.Generic;
using System.Linq;
using System.ServiceProcess;
using System.Text;
using System.Configuration.Install;
using System.Reflection;
namespace Installer
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
static void Main(string[] args)
{
Console.WriteLine("MASDjhd");
string parameter = string.Concat(args);
switch (parameter)
{
case "--install":
ManagedInstallerClass.InstallHelper(new string[] { Assembly.GetExecutingAssembly().Location });
break;
case "--uninstall":
ManagedInstallerClass.InstallHelper(new string[] { "/u", Assembly.GetExecutingAssembly().Location });
break;
}
}
}
}
Here is my InnoScript:
[Setup]
AppName=MachineVerification
AppVersion=1.0
DefaultDirName={pf}\MachineVerification
DefaultGroupName=MachineVerification
UninstallDisplayIcon={app}\MachineVerification.exe
Compression=lzma2
SolidCompression=yes
[Files]
Source: "Installer.exe"; DestDir: "{app}"
[Run]
Filename:"{app}\Installer.exe"; Parameters: "--install"
[UninstallRun]
Filename: "{app}\Installer.exe"; Parameters: "--uninstall"
Help? D:
Found my answer here: Self install windows service in .NET c#
For those you who want to follow the link, the solution is to add:
var processInstaller = new ServiceProcessInstaller();
var serviceInstaller = new ServiceInstaller();
//set the privileges
processInstaller.Account = ServiceAccount.LocalSystem;
serviceInstaller.DisplayName = "MachineVerification";
serviceInstaller.StartType = ServiceStartMode.Automatic;
//must be the same as what was set in Program's constructor
serviceInstaller.ServiceName = "MachineVerification";
this.Installers.Add(processInstaller);
this.Installers.Add(serviceInstaller);
to the constructor of your install class in your service.
I am using the following code under ASP.NET 4.0 framework to obtain the version of MSI file from a web app:
string strVersion = "";
try
{
Type InstallerType;
WindowsInstaller.Installer installer;
InstallerType = Type.GetTypeFromProgID("WindowsInstaller.Installer");
installer = (WindowsInstaller.Installer)Activator.CreateInstance(InstallerType);
WindowsInstaller.Database db = installer.OpenDatabase(strMSIFilePath, 0);
WindowsInstaller.View dv = db.OpenView("SELECT `Value` FROM `Property` WHERE `Property`='ProductVersion'");
WindowsInstaller.Record record = null;
dv.Execute(record);
record = dv.Fetch();
strVersion = record.get_StringData(1).ToString();
dv.Close();
//db.Commit();
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(dv);
System.Runtime.InteropServices.Marshal.FinalReleaseComObject(db);
}
catch
{
//Failed
strVersion = "";
}
It works fine except that when the code finishes running it holds an internal MSI file handle so when I try to move or rename the MSI file I get the error that the file is still in use. This continues until I actually navigate away from the ASPX page that calls the method above.
My question is, I obviously didn't close some handle or object in the code above. But what could that be?
PS. I'm testing it in a development IDE from VS2010.
EDIT: Edited the code like it should be after Adriano's suggestion. Thanks!
The COM object has not been released (it should be auto-released when it goes out of scope but in .NET this doesn't work really well). Because it does not implement the IDisposable interface you can't call its Dispose() method and you can't use it inside an using statement. You have to explicitly call Marshal.FinalReleaseComObject. For example:
try
{
// Your stuffs
}
finally
{
dv.Close();
Marshal.FinalReleaseComObject(dv);
Marshal.FinalReleaseComObject(db);
}
Moreover note that you do not really need a call to the Commit() method because you didn't make any change but just a query.
FWIW, you should be using Windows Installer XML (WiX) Deployment Tools Foundation (DTF). It's an FOSS project from Microsoft that can be found on CodePlex. It has MSI interop libraries with classes that are very similar to the COM classes but implement IDisosable and use P/Invoke instead of COM behind the scenes. There is even support for Linq to MSI if you want. And the full source code is available.
DTF is the gold standard for MSI interop in a .NET world. Here are two examples:
using System;
using System.Linq;
using Microsoft.Deployment.WindowsInstaller;
using Microsoft.Deployment.WindowsInstaller.Linq;
namespace ConsoleApplication3
{
class Program
{
const string DATABASE_PATH = #"C:\FOO..MSI";
const string SQL_SELECT_PRODUCTVERSION = "SELECT `Value` FROM `Property` WHERE `Property`='ProductVersion'";
static void Main(string[] args)
{
using (Database database = new Database(DATABASE_PATH, DatabaseOpenMode.ReadOnly))
{
Console.WriteLine(database.ExecuteScalar(SQL_SELECT_PRODUCTVERSION).ToString());
}
using (QDatabase database = new QDatabase(DATABASE_PATH, DatabaseOpenMode.ReadOnly))
{
var results = from property in database.Properties where property.Property == "ProductVersion" select property.Value;
Console.WriteLine(results.AsEnumerable<string>().First());
}
}
}
}
try to Dispose the Objects.
dv.Dispose();
db.Dispose();