Support forum of the software localization tool Sisulizer


.NET, Delphi, ... - Sisulizer Localization Tool Support Home

Get in contact with the makers of Sisulizer.
Our forum is open for all questions around Sisulizer from customers and prospects.
Don't hesitate to register and ask. The Sisulizer team will answer ASAP.

Search     Help Home Sisulizer Website Download
Search by username
Not logged in - Login | Register 

 Moderated by: Sisusupport, Renate.Reinartz, Markus.Kreisel, Ilkka.Salmenius
New Topic Reply Printer Friendly
Support environment variables in sourcefile paths - Wish list for software localization tool - Technical Support (You need to be registered at the forum to write) - .NET, Delphi, ... - Sisulizer Localization Tool Support
AuthorPost
 Posted: Fri Jul 11th, 2014 11:34 am
PM Private Upload Quote Reply
Markus Hastreiter
Member
 

Joined: Fri Jul 20th, 2007
Location: Kempten, Germany
Posts: 46
Status: 
Offline
It would be very nice if Sisulizer would support environment variables in the path for source files (I'm talking about the "name" attribute in the <source> tag of the Sisulizer project file) as it would better support build server scenarios.

Let me give you an example: we use CruiseControl.Net as a build server. The build server builds a "Nightly Build", as well as several version branches. Each branch has it's own Sisulizer project file. CruiseControl provides a separate working directory for each project and this is where all the binaries are build into. These are the files that Sisulizer operates on, so the Sisulizer project file contains a path to this CruiseControl working directory (for instance for the NightlyBuild "c:\CruiseControl.NET\server\NightlyBuild\WorkingDirectory\myExe.exe"

At the moment, if we create a new version branch, we open the Sisulizer project file in Notepad and manually replace all occurences of "NightlyBuild" with "Branch_VersionX".

CruiseControl automatically provides several environment variables, like "CCNETWORKINGDIRECTORY" which we already use in our build scripts.

It would be much simpler, if we could use these environment variables also for Sisulizer projects. We could simply specify something like "${CCNETWORKINGDIRECTORY}\MyExe.exe" as the source file, so that Sisulizer would automatically always use the correct path.

Maybe (hopefully) you can consider that as a feature for future releases.

Thanks,
Markus

Back To Top PM Private Upload Quote Reply

 Posted: Sat Jul 12th, 2014 01:10 am
PM Private Upload Quote Reply
Markus.Kreisel
Administrator


Joined: Sat Apr 8th, 2006
Location: Monschau, Germany
Posts: 3172
Status: 
Offline
Hi,

good news, our R&D liked the idea an placed it onto their todo list.

Markus



____________________
http://www.sisulizer.com - Three simple steps to localize
Back To Top PM Private Upload Quote Reply

 Posted: Mon Jul 14th, 2014 05:49 pm
PM Private Upload Quote Reply
Markus Hastreiter
Member
 

Joined: Fri Jul 20th, 2007
Location: Kempten, Germany
Posts: 46
Status: 
Offline
Hi,

that's indeed good news. Not only will it help make our version builds easier, it also helps to justify (internally) why we should upgrade to Sisulizer 4.

Thanks,
Markus

Back To Top PM Private Upload Quote Reply

 Posted: Wed Sep 17th, 2014 06:18 am
PM Private Upload Quote Reply
SoloTOH
Member
 

Joined: Tue Mar 8th, 2011
Location:  
Posts: 53
Status: 
Offline
Hi,

was this feature already implementet in one of the last builds?
I checked the version history and I am not sure if it was implemented in Sisulizer 4.0 build 351. ".NET: If the sign key file if the project file (.csproj or .vbproj) contained variable (e.g. $(SharedDir) Sisulizer did not find the key file and could not sign the localized assemblies."


Best regards
Tobais

Back To Top PM Private Upload Quote Reply

 Posted: Mon Nov 17th, 2014 11:08 am
PM Private Upload Quote Reply
Markus Hastreiter
Member
 

Joined: Fri Jul 20th, 2007
Location: Kempten, Germany
Posts: 46
Status: 
Offline
Any ETA on that? No pressure, I'd just like to know. As mentioned it would help to justify the upgrade to Sisulizer 4.

Thanks,
Markus

Back To Top PM Private Upload Quote Reply

 Posted: Fri Jan 15th, 2016 12:27 pm
PM Private Upload Quote Reply
Markus Hastreiter
Member
 

Joined: Fri Jul 20th, 2007
Location: Kempten, Germany
Posts: 46
Status: 
Offline
We're on Sisulizer 4 now, but it would still be a useful feature for our build process.
Do you have any new information on whether this feature will be implemented (and when)?

Thanks,
Markus

Back To Top PM Private Upload Quote Reply

 Posted: Fri Jan 15th, 2016 04:04 pm
PM Private Upload Quote Reply
Ilkka.Salmenius
Administrator


Joined: Wed Aug 8th, 2007
Location: Tokyo, Japan
Posts: 2010
Status: 
Offline
Markus Hastreiter wrote:
It would be much simpler, if we could use these environment variables also for Sisulizer projects. We could simply specify something like "${CCNETWORKINGDIRECTORY}MyExe.exe" as the source file, so that Sisulizer would automatically always use the correct path.


I have hit into the same problem myself. We use TFS build and it is so annoying that the file structure in the build environment is different that in the development envirenment. Now I need to so something into this.

Is this CCNETWORKINGDIRECTORY environment variable something that is also defined in the development machine. I mean if we supported environment variable it would be needed that both development and build machine would contain thos variable.

Ilkka



____________________
http://www.sisulizer.com - Three simple steps to localize
Back To Top PM Private Upload Quote Reply

 Posted: Wed Apr 20th, 2016 11:50 am
PM Private Upload Quote Reply
Markus Hastreiter
Member
 

Joined: Fri Jul 20th, 2007
Location: Kempten, Germany
Posts: 46
Status: 
Offline
Sorry, I totally missed your post. In this special case, CCNETWORKINGDIRECTORY is an environment variable that is only available on the build server (working directory used by CruiseControl.Net) during the build job.
But for our use-case this would be ok, because developers don't touch the Sisulizer project. Only the one developer that is responsible for the build server updates the Sisulizer project file and this is done directly on the build server. So we would simply require that this person updates (or sets) the environment variable before opening the Sisulizer file.
For instance, we add a new assembly via Sisulizer UI, save, then open the slp file in notepad++ and replace the path with the environment variable.

However, we are currently looking into moving to Jenkins as a build server. Here we would be able to use relative paths and would therefore no longer require support for environment variables. But it's not yet decided.

Thanks,
Markus

Back To Top PM Private Upload Quote Reply

Current time is 08:24 pm  
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Wish list for software localization tool > Support environment variables in sourcefile paths



WowUltra modified by Sisulizer Copyright © 2007-18 by Jim Hale - Based on WowBB Copyright © 2003-2006 Aycan Gulez

Impress - Privacy statement

Sisulizer software localization tool - Three simple steps to localize