In my WPF caliburn.micro application, I use ComponentOne's C1DocumentViewer to display a report.
I created in the project a new Folder “Reports” and placed the .xml there. I show the report using C1DocumentViewer. When provide the absolute path to the .xml file, it works fine. But of course I need to use a relative path. So if I make it “../../MyProject/Reports/MyReport.xml”, it works on my machine when I run it in Visual Studio. But not when I publish it using ClickOnce, it just cannot find the file. Same thing if I use “/Reports/MyReport.xml” or “Reports/MyReport.xml”.
When I try to use “Reports/MyReport.xml” when I debug in Visual Studio, it is looking for the path “Reports/MyReport.xml” in bin/Debug of the main project of the solution.
Please help. Here is my code:
protected override void OnViewLoaded(object view)
{
base.OnViewLoaded(view);
var rpt = new C1.C1Report.C1Report();
rpt.Load(#"Reports/MyReport.xml", "Recent Files Information");
rpt.DataSource.RecordSource = "MyReportProc(1)";
rpt.Render();
Report = rpt.FixedDocumentSequence;
}
Just a guess. Your problem might be related to the working directory of your process.
When the process refers to a file using a simple file name or relative
path (as opposed to a file designated by a full path from a root
directory), the reference is interpreted relative to the current
working directory of the process.
Check it with Directory.GetCurrentDirectory() when you run your program in Visual Studio and also when you run it after publishing it with ClickOnce.
Related
I've been working on trying to figure out why our auto-generated deploy.cmdscripts will not work when installed to C:\Program Files (x86)\OurProgram. I finally narrowed down the issue to the closing parenthesis in (x86) as the script would terminate with "Files was unexpected at this time". One possible solution was to manually create another batch file to set _DeploySetParametersFile to a Windows path ( C:\Program^ Files^ (x86^)\OurProgram\Program.Parameters.xml). This isn't a valid solution for me, so I dug into the auto generated file and found the issue to be 2 variables:
RootPath
_DeploySetParametersFile
Both of which were referenced using %'s(i.e. %RootPath%), however as soon as they were changed to !'s(i.e. !RootPath!), no 2nd script was needed and I can run the cmd script from Program Files (x86) just fine. The issue of course with this is, the deploy.cmd file is auto-generated on each build, thus I have to change it for each build I do. My question is this: Is there a way to edit the template Visual Studio uses to generate the deploy.cmd file? If so, where? It seems so ridiculous that Microsoft would have this be an issue in their web deployment.
How to access TFS build agent folder path in using batchfile?
I am calling runscript tool from build workflow (calling windows batchfile).
I tried to use the environment variable BUILD_REPOSITORY_LOCALPATH ($(BUILD_REPOSITORY_LOCALPATH), $env:BUILD_REPOSITORY_LOCALPATH) but they dint give any result.
Need some assistance on this.
I used another workaround for this instead of getting by workspace. From sourceDirectory folder i drill down to find my solution project file, the path containing my solution project is the local directory path i need
From batchfile i call my exe and pass %TF_BUILD_SOURCESDIRECTORY% as parameter.
string[] subdirectoryEntries = Directory.GetDirectories(targetDirectory)
// targetdirectory would be the input parameter from batch file`
for (int i = 0; i < subdirectoryEntries.Length ; i++)
{
// My root folder always contains a specific folder with name MyFolder
// and a file Myfile.sln
if (subdirectoryEntries[i].ToString().ToLower().Contains(#"MyFolder"))
{
Console.Writeline("My source code path is " + targetDirectory);
}
//Similarly I check for Myfile.sln and then get my path.
}
This may be a very crude way, this worked for me.
The variable you are looking for is TF_BUILD_SOURCESDIRECTORY. Please refer to the XAML build documentation.
TF_BUILD_SOURCESDIRECTORY: The sources sub-directory of the build agent working directory. This directory contains your source code. For example: C:\Build\BuildBot3\CoolApp\CIBuild\src.
If you want to get C:\TFS_Build\src\V9, it's just local path: the path that you have mapped the server path to on your machine. There is not any built-in TF_BUILD environment variables could achieve your requirement.
You could use TFS API to get the related info, first get the workspace information for the build server's workspace, then do the get option, a sample code for your reference:
// Get the workspace information for the build server's workspace
var workspaceInfo = Workstation.Current.GetLocalWorkspaceInfo(sourcesDirectory);
// Get the TFS Team Project Collection information from the workspace cache
// information then load the TFS workspace itself.
var server = new TfsTeamProjectCollection(workspaceInfo.serverUri);
var workspace = workspaceInfo.GetWorkspace(server);
Once you have a workspace, you can query it for the path mappings. It
will do the necessary translation from server to local path based on
your workspace mappings. For example:
workspace.GetServerItemForLocalItem("C:\TFS_Build\src\V9");
and
workspace.GetLocalItemForServerItem("$/DEV/V9");
This mechanism will only work, however, if your build definition
actually sets up the workspace to include these files.
More details please refer this similar question: How do I resolve the root and relative paths of TFS folders on the server?
update from OP:
From sourceDirectory folder i drill down to find my solution project
file, the path containing my solution project is the local directory
path i need
I have a WPF application, when double click from it is location it runs - no problems.
When I trying to start the app from command prompt I get an error.
I need to run the app from command prompt (also using startup register)
Files that help describe the problem:
C:\Users\xxx\AppData\Local\Temp\WERC6F9.tmp.WERInternalMetadata.xml
C:\Users\xxx\AppData\Local\Temp\WERE6F8.tmp.appcompat.txt
C:\Users\xxx\AppData\Local\Temp\WERE718.tmp.mdmp
What could be the problem
I hope this can help you
This could be because of Path. When you Double click app the required files for the application will there at the current folder hence the application is able to find and load the files required. But if your executing it from different path other than app path, lets say
Your application is present in the location D:\Data\Example.exe.
And your executing the app from different location Say C:\Program files, now the app will start running from C:\Program files and it'll start searching required files at C:\Program files and some temp locations once it don't find there it'll throws exception
You can do like this
Write a Batch file.first change the current directory to application directory in this case say D:\Data or you can add your application path to path environment variable and use it
Then Invoke the exe
Save the this file and you call this file from where you want
I had the same issue.
I found out that it was due to me using Debug not Release while building my application. The Microsoft .dll-s in the redistributable is for release.
I have an inno setup code which works fine. Can anyone tell me how to make a bat file from an inno setup code so that a single click will initiate the installation set up.I have done that for java class files.Any help is appreciated.
There should be no need for a .bat file. Inno Setup creates a stand-alone executable (by default named Setup.exe) that you can simply double-click like any other Windows executable.
The executable it creates is nameable either by renaming the Setup.exe to a different name (YourAppSetup.exe, for instance) manually, or by using the OutputBaseName value in the [Setup] section. You can control where the setup executable is created by using the [Setup] section value OutputDir. Here's an example, from the CodeExample1.iss' sample provided in yourInno Setup` installation:
[Setup]
AppName=My Program
AppVersion=1.5
DefaultDirName={code:MyConst}\My Program
DefaultGroupName=My Program
UninstallDisplayIcon={app}\MyProg.exe
InfoBeforeFile=Readme.txt
OutputDir=userdocs:Inno Setup Examples Output
This creates the default Setup.exe in the userdocs: (your My Documents folder), in a subfolder named Inno Setup Examples Output. To put it somewhere else, just change the OutputDir entry to a different location. For instance, to put it in a sub-directory of your source folder named Installer, just use
OutputDir=Installer
For more info, see the documentation, in the Setup Script Sections->[Setup] Section Directives branch.
To change the name from Setup.exe to something else, add a new entry:
OutputBaseName=MyAppSetup
I created a WPF test project, single Window with a single button in it. I then unloaded the project and modified the csproj to contain the following <UICulture>en-US</UICulture>. After rebuilding the build folder now contains a subfolder named en-US and it contains a file called WpfLocalizationTest.resources.dll. All clear so far.
Then I downloaded the source code for Locbaml and built it. (Couldn't find a binary download anywhere, go figure.)
Then I copied the Locbaml.exe to the en-US folder and tried the following.
locbaml /parse WpfLocalizationTest.resources.dll /out:test.csv
This results in an error 'Could not load file or assembly WpfLocalizationTest.resources.dll or one of its dependencies. An attempt was made to load a program with an incorrect format.'
In the obj\x86\Debug folder there's a file called WpfLocalizationTest.g.en-US.resources. I tried running locbaml on that, but the result was the same.
How is locbaml supposed to be used? MSDN is full of cockamamie samples, none of which work. Is locbaml really how Microsoft intends WPF apps to be localized? Or have they come up with proper tools for the job?
As I continue to search I found another link here on Stackoverflow. The compile errors we were originally receiving were related to an outdated LocBaml project not being set for .Net4.0. This is why I was unable to generate teh CSV from the DLL and had to go straight at the resource file. Follow this link for more details. Locbaml localization of .net wpf4 application
This link provides a link to .net 4 binaries which once compilied allow you to go straight at the dll to generate the CSV using LocBaml.
Just an update I pulled my notes this morning. Hopefully this will help get you a bit further along.
Once the project has been compiled copy the LocBaml.exe to the project directory where the build has been generated : In my instance I copied the file to E:\localiztion_sample\localiztion_sample\obj\x86\Release
This is the tricky part in that the build did not contain all the DLL files from the bin directory (telerik controls and other assemblies). As a result I went to bin\release\ and copied all the DLL and resource files from there into the obj\x86\Release directory. For files where I was prompted to overwrite I looked to see if there was a difference in filesize or date created and if not I skipped the copy for these objects.
NOTE: In order for me to generate the CSV I had to copy dll and resource files from the bin directory and place them in the obj directory. Omitting this step will result in the CSV file being created but not populated with data.
Once you have copied the necessary files to the directory you will then parse the .resource file located within the Release directory.
In my project the resource file was located at:
E:\localiztion_sample\localiztion_sample\obj\x86\Release
And the file name was titled: localiztion_sample.g.en-US.resources
Note: this is different from the instruction on the Microsoft website. Microsoft states that you should run the LocBaml tool on the dll file located within the en-US directory. However after multiple attempts and research I found that this in fact caused a number of problems with compatibility between 32 and 64-bit builds as well as it just flat out not working.
In reading through wpf4 unleashed as well as online forums it is suggested to instead point to the *.gen.en-Us.resources file. * = the project name and gen.en-Us reflects the development language chosen
Within the VS command untility you will then need to enter the following
LocBaml /parse filename.resources /out: sample-en.csv
Notes: It is assumed that you have copied the LocBaml file to the root directory where this file exists and that you are running the command prompt as system administrator. For ease of use I changed the working directory within the command prompt to the VS project directory
For my sample project the command looked as:
*LocBaml /parse localization_sample.g.en-US.resources /out: sample-en.csv*
This command then generates the CSV file which acts as a definition of the current project
This was as far as I got I was able to modify teh file and regenerate the dll but I was not able to get the culture to change within the application so I am still working on this piece. I'll reposte once I get it working.
1) Unload project you want to localise
2) Edit Project .cproj file
3) Add property group at the end of the last property group
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
en-GB
4) Reload project and compile this would create a satellite assembly "yourlibrary.resources.dll" inside en-GB folder at bin\debug location, this assembly would be the default assembly.
5) Open Properties\AssemblyInfo.cs file and uncomment this line [assembly: NeutralResourcesLanguage("en-GB", UltimateResourceFallbackLocation.Satellite)] this is a fallback satellite assembly. And we need this entry otherwise for wpf application it throws exception around app.xaml.cs couldn't load
6) From command prompt run this command which uses msbuild to generate UID C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /t:updateuid . \yourlibrary.csproj, open xaml file and check your controls there would be UID on all elements.
7) Download locabaml.exe source code tool from https://github.com/JeremyDurnell/locbaml
8) Copy locabaml.exe file to the \yourprojectname\bin\debug folder
9) we would now create an satellite assembly for french. First we need to parse the default satellite assembly and write out the contents to a csv file as shown here
10:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /parse C:\yourprojectname\bin\Debug\yourlibrary.resources.dll /out:C:\yourprojectname\bin\Debug\yourlibrary.resources_FR.csv
11) Open yourlibrary.resources_FR.csv make necessary translations
12) Now we need to create a satellite assembly in french using command line
13) C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /generate C:\yourprojectname\bin\Debug\yourlibrary.Resources.dll /trans: C:\yourprojectname\bin\Debug\yourlibrary.resources_FR.csv /out:C:\yourporjectname\bin\Debug\temp /cul:fr-FR
14) The command above would create a folder fr-FR at \bin\debug location
15) Switch your computer region settings to french(France)
16) In the code set localisation to Thread.CurrentThread.CurrentCulture = CultureInfo.CurrentCulture;
Thread.CurrentThread.CurrentUICulture = CultureInfo.CurrentUICulture;
17) Compile and run application you would see translated text on the controls