Alrighty, so I'm working on an older application that was built using Enterprise Library 5 and am updating it to use the latest version (6.0.1304). However, I'm running into an issue in a few of the data access pieces that are trying to use EnterpriseLibraryContainer like so:
EnterpriseLibraryContainer.GetInstance(Of Database)(ConfigurationManager.ConnectionStrings("SomeDatabaseWeUse").Name)
My question is, what is an example of replacing this older code?
I did see this
The bootstrapping code for all of the blocks has changed in version 6 of Enterprise Library. The blocks no longer use Unity to manage the initialization and configuration, and each block now includes its own bootstrapping code. Any calls to the EnterpriseLibraryContainer.Current.GetInstance method to resolve a type from one of the Enterprise Library blocks should be replaced with the block specific bootstrap code.>
Buuuuut I couldn't find any examples particular to GetInstance so maybe I completely understand what it means to replace it with block specific code :x
Solution I ended up using:
Dim factory As DatabaseProviderFactory = New DatabaseFactory
db = factory.Create(ConfigurationManager.ConnectionStrings("SomeDatabaseWeUse").Name)
Related
After doing the general upgrade steps for the migration. My razor had 100's of errors suddenly after removing Microsoft.AspNetCore.All. These error were not consistent, these were general compiler errors.
Some combination of
IDE1007 C# The name does not exist in the current context.
CS0111 C# Type already defines a member called with the same parameter types
CS0538 C# in explicit interface declaration is not an interface
CS0116 C# A namespace cannot directly contain members such as fields
or methods
CS8107 C# Feature is not available in C# 7.0. Please use
language version 9.0 or greater.
Just all over the place stuff, and this was all working perfectly in 2.2
I was able to fix this. What I found was that we had few places in the code where we were using # inside a razor block, this used to work fine but breaks in core 3.1. I am assuming that the process of generating the classes by Razor SDK was failing because I was also getting errors in index.g.cshtml.cs.
We probably had this issue in 5 files at most but we were getting 500+ build errors. Very frustrating, so adding this answer because I was not able to find any similar answer anywhere.
Example of bad code, notice the extra # inside {}.
#{ var replacements = new string[] { #Model.TotalItemsInCart.ToString() };}
I am porting an old (circa year 2000) IBM VAST 4.5 application to VA Smalltalk.
I managed to import the app from the VAST repository to my new VA Smalltalk repository with no error messages. But when I try to load the application this error occurs:
Error: 365 Cannot complete the load because CwItem can only be
defined by one of ('CwControls V 4.5a' 'CwWindowsControls V 8.6.0
[269]').
I understand that CwControls changed to CwWindowsControls but my Smalltalk knowledge is very rusty: I have no idea how to solve this.
Someone in the VA Smalltalk group mentioned a similar situation but his answer is a bit cryptic to me:
"CwControls app name is changed in new version as CwWindowsControls. When I create a empty app named CwControls, I can load apps uses controls in this app."
I know that I can create an empty app called CwControls but then my application will not compile as the methods normally provided by the original CwControls will not be present.
How can I solve this problem?
Thank you very much!!
It looks to me like CwWindowsControls already defines CwItem. When you load CwItem from the other project it is defined by CwControls though. I'm not familiar with VA but you might be able to resolve the issue by first deleting CwItem where it's defined by CwWindowsControls, then loading the other project and finally (possibly) refactor CwItem to be defined by CwWindowsControls.
I found a way to solve my problem.
My application needed another application called CwControls. But CwControls had changed its name to CwWindowsControls.
So, inspired by the answer by #MikeLeske, I just created an empty app called CwControls. That way VA Smalltalk let me continue the load.
Another error appeared then:
"Error: 365 Cannot complete the load because AbtCwPanel can only be defined by one of ('AbtRunWinCwControlsApp V 4.5' 'AbtWinRunViewsSubApp V 8.6.0 [269]')."
But the answer was similar: I just created an empty app called AbtRunWinCwControlsApp.
Now I have my 13 year old application loaded into my image. Time to work!!!
Thanks.
I had a similar problem, but with SstHttpSupport which became SstHttpCommunications and such.
I fixed this by "Managing" the application and removing the requirement for SstHttpSupport.
I then successfully ported the application into VAST 8.6.
Knowing that I no longer had SstHttpSupport, I add SstHttpCommunications as the new requirement in 8.6.
Hope this helps
In my application i have worked for some part of the next version implementations,
So we need to prevent those some implementations for this version.
our superiors asked me to do with pre macro processor, having #ifDef, endif like that and you need to define the version number in buildsettings as preprocessor macro
I have added a user defined setting 'App_Version' in build Setting,
"
How do i use it like
#ifDef AppVersion 1.0
NSLOG (current version implementation)
else
NSLOG (NEXT version implementation)
Actually i was not much awair on it, so that my interpretation was poor
#if App_Version == 1.0
I don't remember exactly how new preprocessor macros are defined in XCode but I don't think that you are defining it correctly. See How do I define preprocessor macros in Xcode 4?
However, using preprocessor macros for such things is far from recommended.
You should
Create a method that will read the application version from the bundle
Call the method to check version and use standard if-elseif-else
With iPhone development I can't really imagine why would you use such a macro/method though. How many versions of an app do you want to build? All the applications I have implemented for iOS needed only 1 version - the latest one. I don't see any reason why would you like to build an older application version from current code.
Use a versioning system and if you are implementing features for the next version into current code, use a dedicated branch! Otherwise it's just a mess and your supervisor is ... not smart ... for not seeing it.
The compiler doesn't need (or want) to know anything about application version (it is information for the application submission process). This should not be done with preprocessor macros, unless you want to define your own (even then, I wouldn't recommend it). You should check the application version at runtime
[[NSBundle mainBundle] objectForInfoDictionaryKey:#"CFBundleVersion"];
and prevent new features from being accessible in the current version based on that. More generally I would consider using branching models like git flow to handle things like that. What will happen when you have 3,4,5 ... versions to handle. The preprocessor macros will become a nightmare to manage.
Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.
I want to implement a Webbrowser in my vb.net (2008)-project, however, I don't like the inbuilt IE.
I also remembered that is was kind of easy to implement a mozilla-tool like the gecko-webbrowser in the past...
It was kinf of more complicated than I remember, as I had to dwnload xulrunner and Skybound.Gecko.dll which both probably have to be included in any publishing of the finished project... I also defined x86 as target CPU and made all the needed steps to use a GeckoWebBrowser within my Application. I also called Skybound.Gecko.Xpcom.Initialize(My.Application.Info.DirectoryPath & "/xulrunner") before compiling it.
However, when I try GeckoWebBrowser1.navigate("http://...") (The element was inserted with this name per designer) the IDE tells me that an objectreference is not set to a objectinstance as if GeckoWebBrowser1 isn't defined yet... but the GeckoWebBrowser1.Created attribute is giving back true.
Does anybody know why it isn't working yet?
I have the same error in my solution. Try to use GeckoFX assembly. I use 15 version dll and error fix.
https://bitbucket.org/geckofx/geckofx-16.0/downloads