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
Related
So i Have this c# application that contains a button allowing a file copy from a network share folder.i use a vbscript to copy the file, this script takes the source and destination path.now i want to create a setup to install my application on any PC connected to the LAN. the thing is the path will eventually change so i'm not sure if it will work.
I never made a setup before and i'm wondering if there is a way to customise the setup to allow the installer to make the changes.otherwise any solution will be very helpfull. thank you
I don't normally like giving answers that are mostly links, but it is too much to post here. Here is a quick summary:
There are quite a few things that can do what you are asking.
The one I like is called Squirrel. I recently had to learn how to use it while deploying an application for my company.
The steps in a nutshell(see what I did there? :)
Build your application (optionally add the update checker code
first - see links for details)
Package your application into a .nuget file using Nuget Package Explorer(details in links below)
Run the squirrel --releasify on your nuget
It will output the setup files that you are looking for in the Releases directory.
More information (that you will likely need):
Github - Squirrel.Windows
Youtube - Video tutorial that I found helpful
Github - Squirrel Getting started guide
As for your vbscript, I would do the file copy inside C#. You are very likely to run into permissions issues when using vbs. In any case, why add the complexity of 2 different languages when C# can do a file copy easily.
Something like this during your application's startup.
if (File.Exists(localFileName) == false) // check to see if the file is needed
{
File.Copy(sourceFileOnLan, destinationFile); // get the file
}
If you are really set on using a vbs file, you can launch it using Process.Start() and let Windows execute it.
Also, you can store the paths in your app.config file, and update them if/when they change.
I have a requirement to use MSDeploy.exe and move the build code from local machine to server machine programatically (Dotnet c#).
I am not sure how to use the MSDeploye.exe and passing the arguments for the destination folders and source folders.
I am little aware that we have an xml file which can be used to pass parameters to the MSDeploy.exe but I am not sure how can I configure the same for my problem.
Thnx in advance.
Sidharth Gupta
How to use MS deploy
The above link has how to use the deployment tool. With command line options etc
such as
ProjectName.deploy.cmd /t "-skip:objectName= filePath,absolutePath=\\ApplicationFolder\\web\.config$"
Web deploy command link reference
has some more specifics
I have files in ...bin/release where is my windows form application, I have used EEPlus library as well. What the files do I need to send to client to have application work correctly?
My files:
name.exe
name.exe.config
name.pdb
name.vshost.exe
name.vshost.exe.config
name.vshost.exe.manifest
EEPlus.dll
EEPlus.xml
I know that first two are mandatory, but what about all rest?
thanks in advance
name.exe //necessary, it is your main executable
name.exe.config //necessary, it is your application config file
name.pdb //not necessary, it contains code and debug symbols configuration of your assembly, but let it be there, it is useful when users encounter a bug or crash
name.vshost.exe //not necessary, it is the hosting process of visual studio for debugging purposes
name.vshost.exe.config //not necessary, config file of name.vshost.exe
name.vshost.exe.manifest //not necessary, manifest of name.vshost.exe
EEPlus.dll //necessary, it is one of your application dependencies
EEPlus.xml //not necessary, contains some information for EEPlus.dll
reference for xml, reference for vshost, reference for pdb
All except *.pdb and *vshost*.
Really you should look at the REFERENCES of your project.
Generically all the assemblies that don't make part of the NET Framework need to be redistributed.
In this case, it seems that you need to distribute EEPlus.dll only.
The other files are there just as a byproduct of the compilation.
Of course, you should also consider that a thirdy party library could need other files, but this should be explained in their documentation under the redistrubute page.
You could try this:
Delete all files except the name.exe, name.exe.config and EEPlus.DLL, then run your app outside VS directly in the BIN\RELEASE folder. However I recommend to have a clean virtual machine where you could test your app and be sure to not forget anything.
Always
name.exe
name.exe.config
Dependency dlls
Interop dlls
First we check this mandatory files before giving to client, because at client, when running application that will be crashed without displaying any errors...
I am building a C# adding for Excel. In order to debug it, I need to launch Excel.exe with a command line argument containing the Debug or Release path to the addin.
For example:
Start External Program: C:\Program Files\Microsoft Office\Office15\EXCEL.EXE
Command line argument "C:\Dev\Project1\Project1\bin\Debug\Project1-AddIn64.xll"
However, I would like to replace "C:\Dev\Project1\Project1\bin\Debug" with an equivalent of $(SolutionDir) for C++ projects in VS. Is there a way to do this ? If it is not doable, is there a way to get around this ?
EDIT: please support me and get this added in VS by voting up the following idea: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6350738-support-for-macros-in-debugging-command-line-argum
Indeed, the macros cannot be used in the Start Options | Command line arguments
I see two solutions:
As the current folder is set to the $(TargetDir) when you Start an application you could refer to the solution folder like this: ..\..\..\ if the External program accepts a relative path. (I am not quite sure why you would ever want to refer to the solution folder, referring to the output/target folder makes more sense to me)
In the Post Build event (unregister) and register the component the way the component should be registered when deploying it (a proper setup). This way you only have to refer to Excel in the Start Action. This also immediately adds the benefit of testing a scenario that is more similar to production.
It's not exactly a fix, but this may help some people. If you create your project from the project template "Visual C#/.NET Core/Console App" instead of "Visual C#/Windows/Console App", this feature is supported. When I put "$(SolutionDir)" in the Application Arguments field on the Debug tab of the Project Properties window, it is expanded at run time. Note that you will need Visual Studio 2015 Update 3 or later.
I guess you could make use of post-build event to read in your file. #HansPassant explained it in VS2010 - Project Macro Variables in Start Options Command Line Arguments.
A short quote:
A possible workaround is a post-build event that writes a file that you read in your program. Like echo $(ProjectName) > "$(TargetDir)cmdargs.txt
You could substitute cmdargs.txt to appropriate file you want.
You CAN use the macros in the Command fields. I used procmon.exe to see what VS was looking for and indeed i could use $(SolutionDir)\..\Debug\thetoolname.exe as my solution was not in the root.
Im using VS2019 so AFAIK it is supported from this version but it most likely is supported in lower versions. Just use procmon to check the path that VS is attempting to resolve.
Whats a good approach for white labeling dll and exe with visual studio?
In essence we want to be able to have the name of the dll and exe change based on the client that we are packaging the solution for, e.g.:
Instead of myCompany.exe and myCompany.db.dll, I would like yourComany.exe and yourComany.db.dll or acme.exe and acme.db.dll, etc
Edit:
Currently we are using a straight visual studio build process with a wix project to create an msi.
If the only justification for rebuilding it is to change the name, can you just use something generic in the first place? Imagine having to patch 50 identical DLLs, and build/deploying each one separately because they all must be named different things. Even if it's only for a few clients, I would hate to have to maintain that. Versioning could be a hassle too.
If you must do it, I would probably go with a build task (which can perform fairly advanced operations). You mention that you are "packaged the solution"; the viability of a build task would depend on how it is being packaged.
In response to your comment about naming the EXEs with client-specific names... My obvious suggestion there would be to have those applications contain as little code as possible.
The simplest build integration I can think of would be to create a post-build task which ran upon successful compilation in release mode. The task could then read a config file which defined the unique names, and copy the successfully built EXEs to an output directory.
Some of the operations can be accomplished just from the task config file: http://msdn.microsoft.com/en-us/library/ms171466.
Alternatively, you might want to create a little application to do all the work for you, and just pass config switches to it.
For example, here is a little post-build command that I execute to minify my JavaScript/CSS upon successful build of a web application. The concept is similar:
build
execute an app (like msbuild.exe, or your custom build app)
pass data to the executable (like paths, switches, etc.)
executable writes the files out
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
"$(ProjectDir)Properties\build\minify.xml"
/p:SourceLocation="$(ProjectDir)client"
/p:CssOutputFile="$(ProjectDir)client\final\final-full.css"
/p:JavaScriptOutputDirectory="$(ProjectDir)client\final"
You could use ILMerge in whatever post-build process you want on all your outputted assemblies (dll and exe), to create one-off customer-branded builds.
ilmerge /out:CustomerName.exe internalName.dll internalName.exe
I don't know that there is a good way to do this without actually building the project as XYZ company. You could try something like this which will give you the desired result BUT it will change the physical name of the assembly as well which may cause dependency problems.