After updating SF I've got an issue that prevents using of SF totally, I'll try to put a problem in words without code.
Service fabric application AppName.SF consists of an AppName.SF.StatefulActor and AppName.SF.StatefulService. Both reference to class library called AppName.Core.
Case 1: StatefulActor not references StatefulService - package performs OK:
AppName.SF\pkg\Debug\AppName.SF.StatefulActor\Code has AppName.Core.dll
AppName.SF\pkg\Debug\AppName.SF.StatefulService\Code has AppName.Core.dll
each package Code folder has AppName.Core.dll. Deployment performs successfully.
Case 2: StatefulActor references StatefulService - package performs BAD:
AppName.SF\pkg\Debug\AppName.SF.StatefulActor\Code has AppName.Core.dll
AppName.SF\pkg\Debug\AppName.SF.StatefulService\Code has no(!) AppName.Core.dll
So I get a missing reference error if I try to deploy application in cluster. Issue appeared after SF updated to 1.4.87-preview.
Looks like you've found a bug - we are investigating. In the interim, it should work if you build using msbuild.
For a workaround add the following to your application project (.sfproj) file:
<Target Name="CopyExtraPackageFiles" AfterTargets="Package">
<Copy SourceFiles="..\AppName.Core\bin\$(Configuration)\AppName.Core.dll"
DestinationFolder="pkg\$(Configuration)\AppName.SF.StatefulService\Code" />
</Target>
This makes some assumptions about the location of your AppName.Core project. Adjust the path if necessary.
This will manually copy AppName.Core.dll to the appropriate location in the package where it is missing.
EDIT:
Or try this for a general purpose workaround instead of the above code snippet. Let me know if it works.
<Target Name="EnsureProjectReferencesAreConfigured" BeforeTargets="GetCopyToOutputDirectoryItems">
<MSBuild
Condition=" '#(ServiceProjectReference)' != '' "
Projects="#(ServiceProjectReference)"
Targets="AssignProjectConfiguration"
Properties="Configuration=$(Configuration);Platform=$(Platform)" />
</Target>
Related
Yesterday I was able to run a plain Java class in Android Studio without any problems. I did this by creating an Application configuration:
... for running the main() method of some class I defined in the default app module, e.g.:
package com.example.myappname;
public class Api {
public static void main(String[] arguments) {
System.out.println("API test");
}
}
If I then pressed run:
... the output (which I can't show you now, because it doesn't work anymore) of main() would appear nicely in the Run Tool Window:
As far as I was aware, no gradle task or build process was invoked by running this type of configuration. But now, all of a sudden, it appears as though gradle is being executed before running, because it complains that task [:app:Api.main()] failed with message:
A problem occurred configuring project ':app'.
> Could not create task ':app:Api.main()'.
> SourceSet with name 'main' not found.
... as seen here:
I tried recreating the configuration and for the first run it worked as before again, but on rerunning the same gradle build error appears again.
Do you have any idea why this is happening and how I can solve this? Am I correct in thinking gradle should be omitted with these kinds of Application configurations?
When it worked, the output in the Run Tool Window would appear almost instantaneously and no elaborate build process appeared in the Build Tool Window, leading me to believe no gradle build process was being executed.
I got it to work again:
... but don't ask me how exactly. It appears to be very buggy.
After deleting all sorts of cache directories and files and searching all kinds of directories for the location of the configuration files I was able to find that the configurations are stored in .idea/workspace.xml of the project.
And one thing I appeared to notice is that the following "hidden" option is needed as a minimum (which I believe was not there, when it didn't work):
<method v="2">
<option name="Make" enabled="true" />
</method>
Here's a full example configuration:
<configuration name="API" type="Application" factoryName="Application" nameIsGenerated="true">
<option name="MAIN_CLASS_NAME" value="com.example.myappname.Api" />
<module name="MyAppName.app.main" />
<method v="2">
<option name="Make" enabled="true" />
</method>
</configuration>
But sometimes it works and sometimes it doesn't. It appears to be the most reliable if I signify the classpath (-cp option in the Android Studio dialog) to be MyAppName.app instead of MyAppName.app.main.
Ironically, it started to work again when the configuration dialog claimed it couldn't find the class I wanted to run and a red X appeared in the top right corner of the configuration icon:
So, it's all a bit of a mystery to me, as to why it sometimes works and other times it does not.
PS: I was wrong about gradle not building in this type of configuration; it does.
And after a few more tests, it appears one simply shouldn't select the ".main" part when choosing a module for the classpath argument, as that appears to be some specific gradle configuration/task I don't understand well enough.
In spite of Android Studio claiming it can't find the class then (and the red X appearing), it works.
I've been trying to get an automatic versioning system going for builds (mainly due to external crash analytics picking up each build as the same until I change the version manually). The format is simple, I take the CFBundleShortVersionString from the Info.plist, and append the current date and time (in yyyyMMddmmss format) as subversion.
The task I've put together for this:
<Project>
<Target Name="BeforeBuild">
<XmlPeek XmlInputPath="$(ProjectDir)Info.plist" Query="//dict/key[. = 'CFBundleShortVersionString']/following-sibling::string[1]">
<Output TaskParameter="Result" ItemName="VersionNumber" />
</XmlPeek>
<PropertyGroup>
<BuildNumber>$([System.DateTime]::Now.ToString(yyyyMMddmmss))</BuildNumber>
</PropertyGroup>
<XmlPoke XmlInputPath="$(ProjectDir)Info.plist" Query="//dict/key[. = 'CFBundleVersion']/following-sibling::string[1]" Value="$(VersionNumber).$(BuildNumber)" />
</Target>
</Project>
However it fails with the following error:
Target BeforeBuild:
[...]/[...].csproj(1069,5): error MSB3733: Input file "[...]/Info.plist" cannot be opened. For security reasons DTD is prohibited in this XML document. To enable DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method.
Done building target "BeforeBuild" in project "[...].csproj" -- FAILED.
What am I doing wrong? There's not much info about this error, at least not much that I could find and would help fixing it.
I have two build projects. lets call them project A and project A.pack. When I force build project A it asks me for Boolean parameter if I want to build project A.pack.
But I can't make in publishers block of project A a correct way to force build the project A.pack. I use conditional task but it doesn't work. In log file ccnet writes only that it fails on conditional task. What a usual way to do this in ccnet?
Update:
Sorry for my English. It's not my first language.
What I wanted to do is this:
In project A I added Boolean parameter:
<booleanParameter>
<name>ExampleParam</name>
<true name="Yes">1</true>
<false name="No">0</false>
<display>Example Param</display>
<default>No</default>
<required>false</required>
</booleanParameter>
And added conditional forcebuild in publishers like this:
<publishers>
<!-- some other tasks .. -->
<conditional>
<conditions>
<compareCondition>
<value1>${ExampleParam}</value1>
<value2>1</value2>
<evaluation>equal</evaluation>
</compareCondition>
</conditions>
<tasks>
<forcebuild>
<project>A.pack</project>
<serverUri>tcp://localhost:21235/CruiseManager.rem</serverUri>
</forcebuild>
</tasks>
</conditional>
</publishers>
When I press "force" it asks me for "Example Param", I check "Yes" and when it finishes building dashboard says that build was succesful but ForceBuildPublisher task failed.
There is no information in server log about why force build task failed.
It's CruiseControl.NET-1.6.7
Update 20150808:
I convinced my colleagues to update CCnet. In version 1.8.5 it's possible to do a conditional build like I wrote.
If the boolean parameter is true then write to a file that A.pack watches. A.pack builds if the file gets dirty. See Filesystem Source Control Block for use by A.pack in listening to the file made dirty by A.
When I build my projects via MSBuilds scripts, I obtain the following message during the work of ClCompile target: Running Code Analysis for C/C++…
Output of MSBuild looks like:
ClCompile:
....
Source1.cpp
Source2.cpp
Running Code Analysis for C/C++…
After changing <RunCodeAnalysis> property in build scripts to false:
<PropertyGroup>
<RunCodeAnalysis>false</RunCodeAnalysis>
</PropertyGroup>
this just disabled running RunCodeAnalysis MSBuild target, but it does not affect running code analysis in ClCompile target - it seems it should be disabled somewhere else.
How can I disable code analysis during execution of ClCompile target?
<EnablePREfast> should be set up to false.
I have used the following code:
<PropertyGroup>
<EnablePREfast>false</EnablePREfast>
</PropertyGroup>
More info at CL Task
In Project Property page, goto Code Analysis (the last one on left tree). There you can disable Code analysis feature. In VC10+, you just need to de-select second check box. In earlier versions, you set third property to No.
When I launch CruiseControl.NET with a particular configuration file I receive the following error:
ThoughtWorks.CruiseControl.Core.Config.ConfigurationException: Duplicate node detected
What does this mean, and what causes it?
I think you have 2 nodes in your config where it only expected one. Is there any chance you could post the config file it is throwing the exception on here as additional information? I'm using cruisecontrol (not the .net version) currently and find it can be very picky about it's XML files (rightly so) but not tell you anything about where in the file the exceptions were thrown from.
I found that I had an incorrectly structured config file. In particular, some blocks were outside of the configuration section. The error pointed to the second of these exec sections- apparently it didn't like that there was more than one of a given section inside the project.
Thus, the error occurred due a config file like this:
<project>
<tasks>
...
</tasks>
<exec>...</exec>
<exec>...</exec>
<project>
In my case I had something like:
<task>...</task>
<sourceControls>...</sourceControls>
<task>...</task>
<publishers>...</publishers>
It didn't like the two "<task>" nodes so I fixed it by removing the first "<task>" node. I was trying to do some stuff before getting the latest from svn, and then doing the build after that in the second "<task>" node. I'll need to revisit how to do that...any suggestions?