|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > SlMake overwrites my release build
|
|
|||
|
.NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > SlMake overwrites my release build
|
| Moderated by: Renate.Reinartz, Markus.Kreisel, Jaakko.Salmenius, Ilkka.Salmenius |
|
||||||||||||||||
| SlMake overwrites my release build - Usage - Three simple steps to localize - Technical Support (You need to be registered at the forum to write) - .NET, Delphi, ... - Sisulizer Localization Tool Support | |||||||||||||||||
| Author | Post | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
|
bikedude Member
|
I recently took over as build master, and my predecessor's make script does something strange. First it invokes MSBuild to build our solutions file, using the Release configuration. But then it invokes SLMake create on the .slp file. This then causes SLMake to invoke MSBuild again, but this time using the Debug configuration. This causes my pure and nice Release build to be overwritten with Debug files. What is the correct way of doing this?
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
bikedude Member
|
Is the best way to do this, to run "slmake.exe create" first, then launch msbuild afterwards? Anyone?
|
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Markus.Kreisel Administrator 
|
Hi, The normal cycle in the GUI is: - Create a project only once with File - New - To update your project do not create a new one and import your translations but use Project - Scan for Changes. This will scan your new binaries and finds new and changed strings. This will also re-use existing translations. In SLMake the general process is the same. Hope this helps Markus
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
bikedude Member
|
Oops, I forgot to turn on email notifications of this topic. The person in charge of the translation use the same project all the time, so I assume she simply scans for changes. Running slmake however falls upon me. Which leads back to my original question: Why is my project then built in debug configuration? I need/want the release configuration.
|
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Markus.Kreisel Administrator
|
Hi, Sounds like your .slp points to the debug files and not to your release files. Perhaps you should double check the paths in the .slp and also in the underlying .NET project file. Something is pointing to your debug files. Remember that Sisulizer's build needs the correct binaries as a template for the localized files it creates. Sisulizer compiles your resources and links them to your binaries. So SLMake has to be the last step in your build process. Hope this helps Markus
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
bikedude Member
|
I'm confused now. What debug files? We launch MSBuild.exe with the /p:Configuration=Release parameter. SLMake doesn't, so we run SLMake first and then run MSBuild afterwards to get the correct configuration. I do suspect we're seeing some strange issues because of this, and it is hardly optimal. But allowing SLMake.exe to overwrite our binaries with the debug build configuration is a big no-no!
|
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Markus.Kreisel Administrator
|
Hi Mike, Somehow you seem to point your SLMake process to an outdated configuration. The regular way is: a) You create your binaries with the MS compiler/linker b) Sisulizer is used to build the needed resources. It has to point to the just created files. The build process will first scan the binaries, then build the resources and finally combine it with your compiled files. So your binaries are a combination of what is compiled in step a plus the localized resources Sisulizer builds. a and b should be invoked from MSBuild in this order. Since I'm not a .NET developer I have to ask our R&D for some clearing information what might happen to you. Markus
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Jaakko.Salmenius Administrator 
|
Have you added Visual Studio project (.csproj or .sln) or assembly file (.exe) into Sisulizer project. Can you upload your project file (.slp) to me. Click Private Upload to upload it. Jaakko
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
robson Member
|
Hello I noticed that this post from few months ago, was not fianlized, and I have related issues that need your advice/help. 1. Sisulizer when configured to run in Debug/Release configuration does behave as expected and creates Debug/Release assemblies. 2. However, every time I perform "scan" operation and save the project, the configuration is overriden again back to "Debug|AnyCPU" !!! 3. As sisulizer is running on the Deployment machine to create the translation assemblies, every time we perform a scan in the command line, sisulizer later build the assemblies in Debug, and therefore triggers building missing "debug" dlls (which don't exist as this is a deployment machine with Release only dlls), ending up corrupting the deployment folder with debug and release mixup. Please advice, Robert
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Janusz Grzybek Super Moderator 
|
robson wrote: 1. Sisulizer when configured to run in Debug/Release configuration does behave as expected and creates Debug/Release assemblies. Thank you for reporting it. I reproduced this issue with SlMake. We let you know about fixing it. Janusz
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Jaakko.Nieminen Administrator
|
The problem was that Sisulizer stores the wrong default output directory into SLP. Even if you changed configuration to Release the default output directory was still in Debug. When scanning Sisulizer fixed this but it was not stored. I fixed this in build 307. Now the default output directory matches the selected configuration. In order to get your project in sync open it using 307, rescan it and finally save it. Jaakko
|
||||||||||||||||
| |||||||||||||||||
| Current time is 11:33 pm | |
| .NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > SlMake overwrites my release build | |
Sisulizer software localization tool - Three simple steps to localize
